From tjc@ecs.soton.ac.uk Wed Jun 1 03:01:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772D1E069E for ; Wed, 1 Jun 2011 03:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr4lA+UOTlKH for ; Wed, 1 Jun 2011 03:01:06 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 329D7E06AF for ; Wed, 1 Jun 2011 03:01:03 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p51A0vJC014323 for ; Wed, 1 Jun 2011 11:00:57 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p51A0vJC014323 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1306922457; bh=+UvQWoJLjzkDV5msXZvOXYBvzg0=; h=Subject:References:From:In-Reply-To:Date:To:Mime-Version; b=r3k1xZRU2a5ewfusjWBpF19s/THYEQm0BTg3kcmWi+X6lOfGLzX8DH8xvwDpX26LM 3gocpDuxVKOaC53hIRGOoE0UoEhWOM+/Yy5gW8DCWZgT04diWVK8/peFtTH3D09Woo OeZdwgHagfaqaSzidi6reTsJKvJ0X8shAcQlWgmk= 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 n50B0v0035608800lr ret-id none; Wed, 01 Jun 2011 11:00:57 +0100 Received: from [IPv6:2001:630:d0:f105:1828:5821:a2e2:6a58] ([IPv6:2001:630:d0:f105:1828:5821:a2e2:6a58]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p51A0oC5030356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 1 Jun 2011 11:00:51 +0100 References: <4DDE8029.70606@globis.net> <4DDE9D05.30605@globis.net> <11d901cc1c08$fc0bce50$f4236af0$@com> <58D476F9-1EFB-48F2-B36E-95BE57260ACC@ecs.soton.ac.uk> From: Tim Chown Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (8J2) In-Reply-To: <11d901cc1c08$fc0bce50$f4236af0$@com> Message-ID: Date: Wed, 1 Jun 2011 11:00:47 +0100 To: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 8J2) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n50B0v003560880000; tid=n50B0v0035608800lr; 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: p51A0vJC014323 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] Subject: Re: Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 10:01:07 -0000 On 27 May 2011, at 01:57, "Dan Wing" wrote: >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of Ray Hunter >>=20 >> So if Happy Eyeballs does have the ambition to be a more generic >> solution to the address family selection problem, it should allow >> tuning of the end node protocol selection parameters by the network >> manager, as Philip Homburg and Marc Andrews have already suggested. >=20 > Such ability is suggested in the I-D, and could be gleaned from > existing DHCPv6 parameters. Or we may decide to define new DHCPv6 > parameters for such tuning. Ray, There is a dhc-based proposal for distributing RFC3484 policy tables. So if y= ou think such a hook is also needed for HE, you can put forward a draft desc= ribing how that would work. Tim= From fred@cisco.com Wed Jun 1 06:55:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD7BE07B6 for ; Wed, 1 Jun 2011 06:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.073 X-Spam-Level: X-Spam-Status: No, score=-110.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYLQtsWB+3g1 for ; Wed, 1 Jun 2011 06:55:05 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 94E21E079C for ; Wed, 1 Jun 2011 06:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=135; q=dns/txt; s=iport; t=1306936505; x=1308146105; h=date:from:message-id:to:subject:cc; bh=mJiVc+43UMLmkpez1FU1swa5eT/+WpvZulEvaVxZU8o=; b=mLCTdeMk1XHoZN6PMBID2XJbjG7c+91kfP0H+PrwBF/BggGh2q6+aXXT plW6mZJrCcFFBQrau1KfKvjsdejns0yaw4rOsGVMQOPmc+duHqjA3+iK+ 1LpzlgJlFTo+VS8W0uRV8rIn7Zm7ajOqnpKjRkYBbarfTT764eAbW8s+V k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIHAH5D5k2rRDoH/2dsb2JhbABTmA8BAY4Td6oxnVCGIASGZZk7 X-IronPort-AV: E=Sophos;i="4.65,303,1304294400"; d="scan'208";a="457783058" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 01 Jun 2011 13:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p51Dt1wX024362; Wed, 1 Jun 2011 13:55:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p51Dt1006812; Wed, 1 Jun 2011 06:55:01 -0700 (PDT) Date: Wed, 1 Jun 2011 06:55:01 -0700 (PDT) From: Message-Id: <201106011355.p51Dt1006812@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-gont-v6ops-ra-guard-evasion@tools.ietf.org Subject: [v6ops] new draft: draft-gont-v6ops-ra-guard-evasion-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:55:06 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-gont-v6ops-ra-guard-evasion. Please take a look at it and comment. From Fred.L.Templin@boeing.com Wed Jun 1 08:05:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5C1E0864 for ; Wed, 1 Jun 2011 08:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DIceECTQdeR for ; Wed, 1 Jun 2011 08:05:52 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id E6C16E088A for ; Wed, 1 Jun 2011 08:05:51 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p51F5mSI011798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Jun 2011 10:05:48 -0500 (CDT) 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 p51F5mKe002629; Wed, 1 Jun 2011 10:05:48 -0500 (CDT) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p51F5kO4002398 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 1 Jun 2011 10:05:47 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Wed, 1 Jun 2011 08:05:46 -0700 From: "Templin, Fred L" To: Dan Wing , "v6ops@ietf.org" Date: Wed, 1 Jun 2011 08:05:45 -0700 Thread-Topic: [v6ops] Subject: Re: Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02 Thread-Index: Acwcc7v0fpKy2EG1Qm21dOTzmk6ZiAABMwfgAN4fOsAAHqT2sA== Message-ID: References: <4DDE8029.70606@globis.net><4DDE9D05.30605@globis.net><4DDEB336.7000701@globis.net><20110527042009.74819FFD8BB@d rugs.dv.isc.org><4DDF3AD7.9090400@globis.net> <9091FF4A-4793-4EED-AAD6-9586 484813C1@nominum.com> <077801cc1ff8$f454a440$dcfdecc0$@com> In-Reply-To: <077801cc1ff8$f454a440$dcfdecc0$@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 Subject: Re: [v6ops] Subject: Re: Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 15:05:53 -0000 Hi Dan,=20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Tuesday, May 31, 2011 6:12 PM > To: Templin, Fred L; v6ops@ietf.org > Cc: 'Andrew Yourtchenko (ayourtch)' > Subject: RE: [v6ops] Subject: Re: Happy eyeballs update,=20 > draft-ietf-v6ops-happy-eyeballs-02 >=20 > > If I set address selection policy rules that de-prefer > > certain IPv6 prefixes (e.g., 2001:db8:0:1::/64) and makes > > them to be of lesser priority than IPv4, will HE respect > > that and use IPv4? >=20 > Not as currently written, no. The steps are=20 > described in > http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-02# > section-5.3 >=20 > An algorithm that uses the host's address selection rules > is easy: getaddrinfo(), then attempt to connect to each=20 > address in the order returned, delaying NNNN milliseconds > between connection attempts. >=20 > What Happy Eyeballs is trying to accomplish is not simply > walking the host's address selection table quickly; Happy > Eyeballs is trying to react to the success (or failure) > of IPv6 or IPv4, with the idea that (a) the address=20 > selection table is incorrect or (b) there is a problem with > the network path. (b) cannot be fixed by the address > selection table. >=20 > There might be some way to get Happy Eyeballs to accomplish > its goal while still honoring the host's address selection > policy rule better. I don't know how to do that, though. > Ideas welcome. All I would ask for is that, if the address selection table prefers IPv4 over a more-specific IPv6 prefix such as a /64, that IPv4 destination addresses be preferred over destination addresses covered by the IPv6 prefix. This is necessary for mature large end-user networks where there is little incentive to break away from the use of IPv4 for intra-network communications. It doesn't seem like too much extra work; do you think HE can do that? Thanks - Fred fred.l.templin@boeing.com > -d >=20 >=20 > = From behcetsarikaya@yahoo.com Wed Jun 1 08:38:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D112FE06DE for ; Wed, 1 Jun 2011 08:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=-0.860, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUoHxWZFEYuB for ; Wed, 1 Jun 2011 08:38:10 -0700 (PDT) Received: from nm21.bullet.mail.sp2.yahoo.com (nm21.bullet.mail.sp2.yahoo.com [98.139.91.91]) by ietfa.amsl.com (Postfix) with SMTP id 7C8B2E0651 for ; Wed, 1 Jun 2011 08:38:10 -0700 (PDT) Received: from [98.139.91.70] by nm21.bullet.mail.sp2.yahoo.com with NNFMP; 01 Jun 2011 15:38:10 -0000 Received: from [98.139.91.22] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 01 Jun 2011 15:38:10 -0000 Received: from [127.0.0.1] by omp1022.mail.sp2.yahoo.com with NNFMP; 01 Jun 2011 15:38:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 312702.16576.bm@omp1022.mail.sp2.yahoo.com Received: (qmail 48033 invoked by uid 60001); 1 Jun 2011 15:38:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306942689; bh=+JRKNalnpK4DumXnbdNgXWLsvOInPBqThWEh4YkAsjA=; 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=ZXLFJkXQH4o2Sgqr3tXlUVLU9FBfXopw0astdX+X+05t0X4ZtQFqCW0wac0cnTJus25tPdBspzwvYaUw6LcooGEb/VF8YAh31JiV4tYm33EKHGN6cUID9bfFhPhZpNXvT+ZcxLebckdcnDp0bYSfen/Wkn6U3CunH+ORNoNk2Bc= 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=qJ+wsqy0L+0Mqf/Zfwc66As9+kQ9ho9nxBdS++vUBiA2XV/n5+R+60Qxiqmrq3AVxqk643kPwlkovwOS+IzfldYjwsaER1nFMFFJZzrHqbYss1odzBhkKGAndRO3H+VyJFkbntePsDUoLxBxPkmB+7O802AEOWU8RtefDmwZHuI=; Message-ID: <785331.40680.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: SzBu5jkVM1kaplAq4Nleoi2ySqUvXOlRz5nSpa_T8gnMWxV BFeccljeR0lRZr0efJXvbOWNBeShc21_9pRFdC_XoiVtNFkzW8pMOml3NbHp l5BHSRJnDhjE4LfkyA_ZEMcrpO6Z3MxWdPdSELdeqipdADE_6xX8965rYE_G hUStJTudUPzcyKlGklloED4NqWluDUVyRyC08DEeffMj8WFK3b2KtqomiWMA GWSAoMnWHQ88Jgl_QzL5oHKehkPeTBnb4xvswkkkVf01d_S_D5kSzDC.ux5f _6hEfosDUAQ5u4lLtMNiaCauJLRfWz5swTuxoyAPZS2zxvisKBinbh734s8P UYUjVzSnpqA0R1CwNwoZysmCwLT4RpdPI1NihYpaNXG5Gors6wTXAW.bFCmH 4isMhnsDfgAWYZw-- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Wed, 01 Jun 2011 08:38:09 PDT X-Mailer: YahooMailRC/570 YahooMailWebService/0.8.111.303096 References: <449804.6587.qm@web111416.mail.gq1.yahoo.com> <2960D350-CDE4-4545-8798-48B110EDD601@gmail.com> Date: Wed, 1 Jun 2011 08:38:09 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen In-Reply-To: <2960D350-CDE4-4545-8798-48B110EDD601@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IPv6 Operations Subject: Re: [v6ops] New Version Notification for draft-sarikaya-v6ops-prefix-delegation-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2011 15:38:11 -0000 If you mean that in addition to an IETF document, a 3GPP document inline with its contents would be good to pursue, I agree. Just like in DHCP PD Exclude draft. In fact 3GPP needs only some content from Section 3.1. I believe some day it will get there. If you have time talk to your 3GPP people, they might volunteer. I am going to try to do the same :-). BTW I believe 23.401 is a better place. Regards, Behcet > I think the question laid by Ole is still valid i.e. whether this I-D is the >"best practice" or good guidance for mobile networks. Clearly the I-D has now >turned to mostly about 3GPP system. And I seriously think the clarification 3GPP >needs for its prefix delegation belongs to TS29.061. For example, it would be >beneficial to state there that all prefixes delegated for PDN Connections are >/64 (obvious) unless the UE is the requesting router, IAIDs could map to TEIDs >etc. Then if we face a problem that requires IETF involvement, we can deal with >it here. > > > - Jouni > > > On May 26, 2011, at 7:59 PM, Behcet Sarikaya wrote: > > > > > > >> > > > >> A new version of I-D, draft-sarikaya-v6ops-prefix-delegation-05.txt has >been > > >> successfully submitted by Behcet Sarikaya and posted to the IETF >repository. > >> > >> Filename: draft-sarikaya-v6ops-prefix-delegation > >> Revision: 05 > >> Title: DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile > >> Networks > >> Creation date: 2011-05-26 > >> WG ID: Individual Submission > >> Number of pages: 12 > >> > >> Abstract: > >> As interest on IPv6 deployment is increasing in cellular networks > >> several migration issues are being raised and IPv6 prefix management > >> is the one addressed in this document. Based on the idea that DHCPv6 > >> servers can manage prefixes, we address prefix management issues such > >> as the access router offloading delegation and release tasks of the > >> prefixes to a DHCPv6 server using DHCPv6 PD. The access router first > >> requests a prefix for an incoming mobile node from the DHCPv6 server. > >> The access router may next stateless or stateful address allocation > >> to the mobile node, e.g. with a Router Advertisement or using DHCP. > >> We also describe prefix management using Authentication Authorization > >> and Accounting servers. > >> > >> > >> > >> > >> > >> > >> The IETF Secretariat > >> > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > From jouni.nospam@gmail.com Wed Jun 1 09:53:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95AEE067E for ; Wed, 1 Jun 2011 09:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.256 X-Spam-Level: X-Spam-Status: No, score=-3.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWl7diWOjxP4 for ; Wed, 1 Jun 2011 09:53:16 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 448ECE0651 for ; Wed, 1 Jun 2011 09:53:16 -0700 (PDT) Received: by ewy19 with SMTP id 19so2546276ewy.31 for ; Wed, 01 Jun 2011 09:53:15 -0700 (PDT) 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=XQCskg485MVsCBXeBeUVYC4ISNHGwqMPG13Dzgh5QcM=; b=FaZVSeepa8Def7Wf96MXPSW3REGsmjan1ll3GAiKWY0CIKyBMCEmb/2OrrVs80epnz ib4JVQWK+e+rZBKh+F4e5se/itFB2ba/CSpI8duWDQgmfLogeULSVpmsZ/zC4oP1iTuO cGYCtxWVBWpby9aqimJSWM4vlAaU5/Y/qaQ6s= 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=stsjILuMcNzVN4hNkVjq1Zjyk8GJetNywyP1IC8ema4TSNyC2zysUjBqMoDdPsIvFY tplE36++5o1gXxUgzeu2surbOiZoDUUX3L/ExRAyZTbA+OhEkM9g+9c1WvrlUXcjPVWZ F53IIjfm7n85AO5j9w5hgoUlTS3/Abf7oWyYw= Received: by 10.14.95.200 with SMTP id p48mr2748957eef.51.1306947194546; Wed, 01 Jun 2011 09:53:14 -0700 (PDT) Received: from a88-114-65-153.elisa-laajakaista.fi (a88-114-65-153.elisa-laajakaista.fi [88.114.65.153]) by mx.google.com with ESMTPS id b1sm828772eeg.5.2011.06.01.09.53.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 09:53:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <785331.40680.qm@web111404.mail.gq1.yahoo.com> Date: Wed, 1 Jun 2011 19:53:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7511052D-17D3-46AA-867D-52195553B16B@gmail.com> References: <449804.6587.qm@web111416.mail.gq1.yahoo.com> <2960D350-CDE4-4545-8798-48B110EDD601@gmail.com> <785331.40680.qm@web111404.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] New Version Notification for draft-sarikaya-v6ops-prefix-delegation-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:53:17 -0000 On Jun 1, 2011, at 6:38 PM, Behcet Sarikaya wrote: > If you mean that in addition to an IETF document, a 3GPP document = inline with=20 > its contents would be good to pursue, I agree. Just like in DHCP PD = Exclude=20 > draft. No, the other way around. First go to 3GPP, do the clarifications there = and then if you find a problem that requires IETF involvement, bring it = here. Just like the exclude thing was done. > In fact 3GPP needs only some content from Section 3.1. I believe some = day it=20 > will get there. If you have time talk to your 3GPP people, they might=20= > volunteer.=20 >=20 >=20 > I am going to try to do the same :-). BTW I believe 23.401 is a better = place. If you are after detail, which I believe is the intent, then stage-3 = documents would be the proper place, not stage-2 like 23.401. - Jouni >=20 > Regards, >=20 > Behcet >=20 >=20 >> I think the question laid by Ole is still valid i.e. whether this I-D = is the =20 >> "best practice" or good guidance for mobile networks. Clearly the I-D = has now =20 >> turned to mostly about 3GPP system. And I seriously think the = clarification 3GPP =20 >> needs for its prefix delegation belongs to TS29.061. For example, it = would be =20 >> beneficial to state there that all prefixes delegated for PDN = Connections are =20 >> /64 (obvious) unless the UE is the requesting router, IAIDs could map = to TEIDs =20 >> etc. Then if we face a problem that requires IETF involvement, we can = deal with =20 >> it here.=20 >>=20 >>=20 >> - Jouni >>=20 >>=20 >> On May 26, 2011, at 7:59 PM, Behcet Sarikaya wrote: >>=20 >>>=20 >>>=20 >>>>=20 >>>=20 >>>> A new version of I-D, = draft-sarikaya-v6ops-prefix-delegation-05.txt has=20 >> been =20 >>=20 >>>> successfully submitted by Behcet Sarikaya and posted to the IETF =20= >> repository. >>>>=20 >>>> Filename: draft-sarikaya-v6ops-prefix-delegation >>>> Revision: 05 >>>> Title: DHCPv6 Prefix Delegation as IPv6 Migration Tool in = Mobile=20 >>>> Networks >>>> Creation date: 2011-05-26 >>>> WG ID: Individual Submission >>>> Number of pages: 12 >>>>=20 >>>> Abstract: >>>> As interest on IPv6 deployment is increasing in cellular = networks >>>> several migration issues are being raised and IPv6 prefix = management >>>> is the one addressed in this document. Based on the idea that = DHCPv6 >>>> servers can manage prefixes, we address prefix management issues = such >>>> as the access router offloading delegation and release tasks of = the >>>> prefixes to a DHCPv6 server using DHCPv6 PD. The access router = first >>>> requests a prefix for an incoming mobile node from the DHCPv6 = server. >>>> The access router may next stateless or stateful address = allocation >>>> to the mobile node, e.g. with a Router Advertisement or using = DHCP. >>>> We also describe prefix management using Authentication = Authorization >>>> and Accounting servers. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 From behcetsarikaya@yahoo.com Wed Jun 1 11:33:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A38F13004C for ; Wed, 1 Jun 2011 11:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLA16FuXJIUB for ; Wed, 1 Jun 2011 11:33:06 -0700 (PDT) Received: from nm28-vm5.bullet.mail.ne1.yahoo.com (nm28-vm5.bullet.mail.ne1.yahoo.com [98.138.91.250]) by ietfa.amsl.com (Postfix) with SMTP id 6B782130047 for ; Wed, 1 Jun 2011 11:33:06 -0700 (PDT) Received: from [98.138.90.55] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 01 Jun 2011 18:33:06 -0000 Received: from [98.138.89.245] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 01 Jun 2011 18:33:06 -0000 Received: from [127.0.0.1] by omp1059.mail.ne1.yahoo.com with NNFMP; 01 Jun 2011 18:33:06 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 44917.44769.bm@omp1059.mail.ne1.yahoo.com Received: (qmail 34993 invoked by uid 60001); 1 Jun 2011 18:33:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306953185; bh=/yzFBveLMrP7rFPmi+5nuYhE4aShYiUY7u7NXdI6EO8=; 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=MTVdE331vXLtYZx7LwChH6lMBqZq24Pbe45ks0pm6z6l7FHU04vRc+b5Tbv0hnyBdxyjsmG/ZN7YmpbKqrV5s+8UZZQRmlyFSMKQUAXonTdTkKD2nSSY2rFgFL/eKbWH8uulmxQupTiY04DTgu/B13kOvo4lAAwHX8sOzhkUuyY= 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=Q09BWhyYZPmGZNvQ0E29nrXuEGA8BHI/Mad91Y8s5B62FlPtFOztg5WbNR+UriQ5jCktgiE8lu15uVH65KfDH9n29DmPeen5rPBxfv0ONuHPQ2xBMUzHkSyxEWTW070DSoBMDrbUyu9USiwv4VRDxL+WRHL/il8u2BltXbXh910=; Message-ID: <589777.33995.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: f.N6b.QVM1lVOgRxnCPHoU2sXR4vWk9gQJfy46XwBuEl68r zWICPRZp10CZpQWPkUavbLn_VSBLQ9rmFUdfcLqB1OEx3nsMoaS_YFM_zvkV wHrp2xfvSIs7gqqoNv1DSFbDqn_Uz6uGawyyXIdZjWMTb1zA8AsDV5nmo4NY 2LIjvLd7Tros_dO45LUbzQYCDh9s9rM95DXHfuQSM06BxuP_Fc1hX1gZDdCk W4TJNSMzY0isc2O_NdWV7AC3g_0H.JZV3MNr5X3xWd7bPTF1DdfffmWc2GiB l1zsy8geIAbbcfq4F7Z9wLOt6JLWpwvVFwTn0PjrTxGDvgmwboxp6b6hyKKo nSAlkp1CZmi.ec.XYsyq3Kdk.E8JUHyBqJszWIsly6Y4J4lAI3wR6zegh.Kd Cb.wjhrg.UAlj0w-- Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Wed, 01 Jun 2011 11:33:05 PDT X-Mailer: YahooMailRC/570 YahooMailWebService/0.8.111.303096 References: <449804.6587.qm@web111416.mail.gq1.yahoo.com> <2960D350-CDE4-4545-8798-48B110EDD601@gmail.com> <785331.40680.qm@web111404.mail.gq1.yahoo.com> <7511052D-17D3-46AA-867D-52195553B16B@gmail.com> Date: Wed, 1 Jun 2011 11:33:05 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen In-Reply-To: <7511052D-17D3-46AA-867D-52195553B16B@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IPv6 Operations Subject: Re: [v6ops] New Version Notification for draft-sarikaya-v6ops-prefix-delegation-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2011 18:33:11 -0000 Hi Jouni, This draft is an IETF draft. I think that discussing what should be done with 3GPP, another SDO is out of scope. If you started the exclude thing in 3GPP, good for you. But what counts is, it is now an IETF draft. Many people expressed positive opinions on draft-sarikaya-v6ops-prefix-delegation so far. All reviews have been taken care of. Behcet > > On Jun 1, 2011, at 6:38 PM, Behcet Sarikaya wrote: > > > If you mean that in addition to an IETF document, a 3GPP document inline >with > > > its contents would be good to pursue, I agree. Just like in DHCP PD >Exclude > > > draft. > > No, the other way around. First go to 3GPP, do the clarifications there and >then if you find a problem that requires IETF involvement, bring it here. Just >like the exclude thing was done. > > > > In fact 3GPP needs only some content from Section 3.1. I believe some day >it > > > will get there. If you have time talk to your 3GPP people, they might > > volunteer. > > > > > > I am going to try to do the same :-). BTW I believe 23.401 is a better >place. > > If you are after detail, which I believe is the intent, then stage-3 documents >would be the proper place, not stage-2 like 23.401. > > - Jouni > > > > > Regards, > > > > Behcet > > > > > >> I think the question laid by Ole is still valid i.e. whether this I-D is >the > > >> "best practice" or good guidance for mobile networks. Clearly the I-D has >now > > >> turned to mostly about 3GPP system. And I seriously think the clarification >3GPP > > >> needs for its prefix delegation belongs to TS29.061. For example, it would >be > > >> beneficial to state there that all prefixes delegated for PDN Connections >are > > >> /64 (obvious) unless the UE is the requesting router, IAIDs could map to >TEIDs > > >> etc. Then if we face a problem that requires IETF involvement, we can deal >with > > >> it here. > >> > >> > >> - Jouni > >> > >> > >> On May 26, 2011, at 7:59 PM, Behcet Sarikaya wrote: > >> > >>> > >>> > >>>> > >>> > >>>> A new version of I-D, draft-sarikaya-v6ops-prefix-delegation-05.txt has > >> been > >> > >>>> successfully submitted by Behcet Sarikaya and posted to the IETF > >> repository. > >>>> > >>>> Filename: draft-sarikaya-v6ops-prefix-delegation > >>>> Revision: 05 > >>>> Title: DHCPv6 Prefix Delegation as IPv6 Migration Tool in >Mobile > > >>>> Networks > >>>> Creation date: 2011-05-26 > >>>> WG ID: Individual Submission > >>>> Number of pages: 12 > >>>> > >>>> Abstract: > >>>> As interest on IPv6 deployment is increasing in cellular networks > >>>> several migration issues are being raised and IPv6 prefix management > >>>> is the one addressed in this document. Based on the idea that DHCPv6 > >>>> servers can manage prefixes, we address prefix management issues such > >>>> as the access router offloading delegation and release tasks of the > >>>> prefixes to a DHCPv6 server using DHCPv6 PD. The access router first > >>>> requests a prefix for an incoming mobile node from the DHCPv6 server. > >>>> The access router may next stateless or stateful address allocation > >>>> to the mobile node, e.g. with a Router Advertisement or using DHCP. > >>>> We also describe prefix management using Authentication Authorization > >>>> and Accounting servers. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> The IETF Secretariat > >>>> > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> > > From cb.list6@gmail.com Wed Jun 1 12:25:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F46E08A6 for ; Wed, 1 Jun 2011 12:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8Cu01rojpfy for ; Wed, 1 Jun 2011 12:25:25 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 84B3113006B for ; Wed, 1 Jun 2011 12:24:13 -0700 (PDT) Received: by wyb29 with SMTP id 29so103086wyb.31 for ; Wed, 01 Jun 2011 12:24:12 -0700 (PDT) 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=p1BTA02osgw8MybGgWp1ImU9IVVV2NkTCcAV2VGI0XU=; b=k6hrbwLxqC+hmNfFz+PI+oj1duNAzGRxVpQ66jO4lPjcGdxHKOxFk6NO9o2ZGu+Qav wR4sxoRS8XWsaADt3bLts2ZANV/6iOWd1ANha5tXfWJWdEBG6miQg4zgbIz7wpIQTSsW wtB2BOLymbWbs3atIEpRTNf4uNU3dT9L8VHsE= 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=vS7YFnWMHNb5n8oJ1OXKmLhiPxK5VXTJ8aeJFk2b0LHxNgB2uTaqMad+2+BcAWnd45 T8afUWz6f6/armTILDcY9kpHPAv72gXvoeJIiKiwiqgo1hQ0BDwRnYAHA1BcWHYr3kEc +iarbea5UOCNO6TZ9jciiejVZJH6OjQFcCTqg= MIME-Version: 1.0 Received: by 10.216.152.170 with SMTP id d42mr8351389wek.39.1306956252434; Wed, 01 Jun 2011 12:24:12 -0700 (PDT) Received: by 10.216.179.199 with HTTP; Wed, 1 Jun 2011 12:24:12 -0700 (PDT) In-Reply-To: <589777.33995.qm@web111415.mail.gq1.yahoo.com> References: <449804.6587.qm@web111416.mail.gq1.yahoo.com> <2960D350-CDE4-4545-8798-48B110EDD601@gmail.com> <785331.40680.qm@web111404.mail.gq1.yahoo.com> <7511052D-17D3-46AA-867D-52195553B16B@gmail.com> <589777.33995.qm@web111415.mail.gq1.yahoo.com> Date: Wed, 1 Jun 2011 12:24:12 -0700 Message-ID: From: Cameron Byrne To: Behcet Sarikaya Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] New Version Notification for draft-sarikaya-v6ops-prefix-delegation-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 19:25:26 -0000 On Wed, Jun 1, 2011 at 11:33 AM, Behcet Sarikaya wrote: > Hi Jouni, > =A0This draft is an IETF draft. I think that discussing what should be do= ne with > 3GPP, another SDO is out of scope. If you started the exclude thing in 3G= PP, > good for you. But what counts is, it is now an IETF draft. > There is a coordination between the IETF and 3GPP outlined in http://tools.ietf.org/html/rfc3113 While there is not much detail about the relationship there, my understanding is that IETF makes the protocols and 3GPP makes the architecture. I believe the document in discussion here is an architecture since it does not specify a new protocol (AFAIK). Therefore, i think the ideas here are better fit for 3GPP. > Many people expressed positive opinions on > draft-sarikaya-v6ops-prefix-delegation so far. All reviews have been take= n care > of. While i work at a mobile network, i cannot really understand this draft and what it is trying to achieve clearly. My confusion starts with Figure 1, which does not look like any GSM/UMTS/LTE network that i have ever seen ... although there is some text that says an access router (AR) is a PDN .... I still do not really recognize it. Possibly this is my fault. It appears this draft just explains how DHCPv6 works at a high level where a PDN talks to a DHCPv6 server and then relays that info as an RA.... If that is all, and I have not missed something, i do not think this draft adds much value. I believe DHCP-PD is clearly defined at a 3GPP Release 10 feature, if i remember correctly.... so it is already being defined there. Once again, sorry if i missed something obviously unique to this draft that would make it a right fit for the IETF and not 3GPP. Cameron > > > Behcet >> >> On Jun 1, 2011, at 6:38 PM, Behcet Sarikaya wrote: >> >> > If you mean =A0that in addition to an IETF document, a 3GPP document i= nline >>with >> >> > =A0its contents would be good to pursue, I agree. Just like in DHCP = =A0PD >>Exclude >> >> > draft. >> >> No, the other way around. First go to 3GPP, do =A0the clarifications the= re and >>then if you find a problem that requires IETF =A0involvement, bring it he= re. Just >>like the exclude thing was =A0done. >> >> >> > In fact 3GPP needs only some content from Section 3.1. I =A0believe so= me =A0day >>it >> >> > will get there. If you have time talk to your =A03GPP people, they =A0= might >> > volunteer. >> > >> > >> > I =A0am going to try to do the same :-). BTW I believe 23.401 is a bet= ter >>place. >> >> If you are after detail, which I believe is the intent, then =A0stage-3 = documents >>would be the proper place, not stage-2 like 23.401. >> >> - =A0Jouni >> >> > >> > Regards, >> > >> > Behcet >> > >> > >> >> I think the question laid by Ole is still valid i.e. whether this =A0= I-D is >>the >> >> >> "best practice" or good guidance for mobile =A0networks. Clearly the = I-D has >>now >> >> >> turned to mostly about 3GPP =A0system. And I seriously think the clar= ification >>3GPP >> >> >> needs =A0for its prefix delegation belongs to TS29.061. For example, = it would >>be >> >> >> beneficial to state there that all prefixes delegated for PDN =A0Conn= ections >>are >> >> >> /64 (obvious) unless the UE is the requesting =A0router, IAIDs could = map to >>TEIDs >> >> >> etc. Then if we face a =A0problem that requires IETF involvement, we = can deal >>with >> >> >> it =A0here. >> >> >> >> >> >> - Jouni >> >> >> >> >> >> On May 26, 2011, at 7:59 PM, Behcet Sarikaya =A0 wrote: >> >> >> >>> >> >>> >> >>>> >> >>> >> >>>> A new version of =A0I-D, =A0draft-sarikaya-v6ops-prefix-delegation-= 05.txt has > >> >> been >> >> >> >>>> successfully submitted by Behcet Sarikaya and =A0posted to the IETF >> >> repository. >> >>>> >> >>>> Filename: =A0 =A0 =A0 =A0draft-sarikaya-v6ops-prefix-delegation >> >>>> Revision: =A0 =A0 =A0 =A005 >> >>>> Title: =A0 =A0 =A0 =A0 DHCPv6 =A0Prefix Delegation =A0as =A0IPv6 Mi= gration Tool in >>Mobile >> >> >>>> Networks >> >>>> Creation date: =A0 =A0 =A0 2011-05-26 >> >>>> WG ID: =A0 =A0 =A0 =A0 =A0 Individual =A0Submission >> >>>> Number of pages: =A0 12 >> >>>> >> >>>> Abstract: >> >>>> =A0 As interest on =A0 IPv6 deployment is increasing in cellular = =A0networks >> >>>> =A0several =A0migration =A0issues are =A0being raised and IPv6 pref= ix =A0management >> >>>> =A0is the =A0one =A0addressed in this document. =A0 Based on the id= ea that > DHCPv6 >> >>>> =A0 servers can manage =A0prefixes, we address =A0prefix management= issues such >> >>>> =A0 as =A0the access =A0router offloading delegation and release ta= sks of =A0 the >> >>>> =A0 prefixes to a DHCPv6 server using DHCPv6 =A0PD. =A0 The access = router > first >> >>>> =A0requests a =A0prefix for an =A0incoming mobile node from the DHC= Pv6 > server. >> >>>> =A0The access =A0router may next stateless or =A0stateful address = =A0allocation >> >>>> =A0 to the mobile node, =A0e.g. with a Router Advertisement or =A0u= sing =A0 DHCP. >> >>>> =A0We also describe prefix management using =A0 Authentication =A0A= uthorization >> >>>> =A0and =A0Accounting =A0servers. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> The IETF =A0Secretariat >> >>>> >> >>> =A0_______________________________________________ >> >>> v6ops =A0mailing =A0list >> >>> v6ops@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fernando.gont.netbook.win@gmail.com Wed Jun 1 17:47:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D74E0816 for ; Wed, 1 Jun 2011 17:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGoN8xoTjwNd for ; Wed, 1 Jun 2011 17:47:43 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC467E06E6 for ; Wed, 1 Jun 2011 17:47:21 -0700 (PDT) Received: by yic13 with SMTP id 13so198143yic.31 for ; Wed, 01 Jun 2011 17:47:21 -0700 (PDT) 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:x-enigmail-version:content-type; bh=M8RftukObEUFPcrqh5rgDwlSIubFDPJ2UvJy7jWRsbE=; b=eS+R3nTJNu1+7dC3hDOYIIoOi0CsyxNtTWWtpP5OrPxrDcRpUfcjRogRfHPJBYB+sL 7f3NviJa2e0iXtnOtn5CP+QjP9axok98GEpF/U6lLes+JKpDHTONk6/bdWS1zA+8Yomy dMPy9/MUmXBNu30/xZbkKRIn+lhRwL0tDw/Jc= 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 :x-enigmail-version:content-type; b=VZ///FrhQfCZ5quQ+D88hf8jxrsgMAaf92b/o8hYdls/FNSSpBeVx/xKlBvy9+mOyw 3wMYm5AEL9YnkkS/qSs/QlbcivL9XGEIXqb9ZQ7xyWl4ACZsReR7/cjjCFfCdqnCncHi iGqihH3JJPxrqRCH9iiBeVBlH/oc/qL1v4Qi8= Received: by 10.91.33.1 with SMTP id l1mr126604agj.207.1306975640050; Wed, 01 Jun 2011 17:47:20 -0700 (PDT) Received: from [192.168.123.103] ([190.48.203.155]) by mx.google.com with ESMTPS id u32sm81433ann.4.2011.06.01.17.47.17 (version=SSLv3 cipher=OTHER); Wed, 01 Jun 2011 17:47:19 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DE6DD93.507@gont.com.ar> Date: Wed, 01 Jun 2011 21:47:15 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IPv6 Operations X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------020407080303090103000404" Cc: Karl Auer Subject: [v6ops] Fwd: Re: Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 00:47:44 -0000 This is a multi-part message in MIME format. --------------020407080303090103000404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: Re: Ra-Guard evasion (new Internet-Drafts) Date: Thu, 02 Jun 2011 10:36:12 +1000 From: Karl Auer To: IETF IPv6 On Wed, 2011-06-01 at 14:20 -0300, Fernando Gont wrote: > * "IPv6 Router Advertisement Guard (RA-Guard) Evasion", available at: > http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt Section 1, second para: "of identifying" should be "to identify" Section 1, third para: "had so far been" should be "have so far been" Section 1, third para: "deemed as appropiate" should be "deemed appropriate" Section 1, fourth para: The techniques could *probably* be exploited. And maybe mention DHCPv6 here as well...? Section 2.1, first sentence is missing words or something. No legitimate what? Section 2.1 first para: should be "simply ignoring". Suggest leaving "simple", "simply" etc out of such sentences. It might not be simple at all. Section 2.1 second para: should be "implement" not "implements" Page 6: This might be a silly thought, but why would the implementation need to do fragment reassembly? All it needs to do is locate RAs, whether they are in fragments or not. It has all the info it needs in the fragment with the RA. That is, it passes earlier packets, but if a fragment arrives with an RA in it, it checks the RA. The destination might end up with a partial packet, but it will never get the damaging fragment, and will eventually discard the partial. End of Section 2.2: "it should be obvious" - well, it isn't :-) Definitely expand on precisely why. Regards, K. PS: Responding on this list, rather than NANOG - is that OK? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --------------020407080303090103000404 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --------------020407080303090103000404-- From fernando.gont.netbook.win@gmail.com Wed Jun 1 18:16:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AB1E0749 for ; Wed, 1 Jun 2011 18:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYjcO7brSq70 for ; Wed, 1 Jun 2011 18:16:35 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18F0FE06A0 for ; Wed, 1 Jun 2011 18:16:35 -0700 (PDT) Received: by yxk30 with SMTP id 30so200127yxk.31 for ; Wed, 01 Jun 2011 18:16:34 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=72l3w4V0cFWWO0Unf2DozVxSk+T0NvmAbIUKG7rzjyo=; b=KoIbLyqeZ7pDqfbA8CwdhwBucWY/YRmfVpcgTUjLG18yp3cmqhIWHjTInUCb+KQGcR oP4svAsE1cPY9rr+VVfU5ABDq4cAvb2NsiukKs76GPSpGtzCzv6xiI3hkfNgJ2t6uN9D cpFXuwS/wo8wJUzfNZf9oahBeJeMbXst0VGyY= 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:content-type :content-transfer-encoding; b=HbkDkpblsZMrQ1F5ArD3Lq1aCfybZdi1zxpDlY3af5xQOpGNNqUpjk7hFX5sKzbQHU 80bWVXsTvYKTTmurKbcstNzItL3MNv6sTnpXktG7LjoEruxBb0TI/VHUZHJTJX9iPm/e O7LrJ4GCLo3zPfd0OZaoQ+/hQdRMDHr+jFLqs= Received: by 10.101.175.33 with SMTP id c33mr75318anp.93.1306977393139; Wed, 01 Jun 2011 18:16:33 -0700 (PDT) Received: from [192.168.123.103] ([190.48.203.155]) by mx.google.com with ESMTPS id r10sm94639anh.2.2011.06.01.18.16.29 (version=SSLv3 cipher=OTHER); Wed, 01 Jun 2011 18:16:32 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DE6E465.9040804@gont.com.ar> Date: Wed, 01 Jun 2011 22:16:21 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Karl Auer References: <4DE674CC.2000402@gont.com.ar> <1306974972.5839.185.camel@karl> In-Reply-To: <1306974972.5839.185.camel@karl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 01:16:35 -0000 Hi, Karl, Thanks so much for your feedback. (I've removed 6man from the recipients, and have added v6ops which is the wg at which this draft is aimed). On 06/01/2011 09:36 PM, Karl Auer wrote: > On Wed, 2011-06-01 at 14:20 -0300, Fernando Gont wrote: >> * "IPv6 Router Advertisement Guard (RA-Guard) Evasion", available at: >> http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt > > Section 1, second para: "of identifying" should be "to identify" Done. > Section 1, third para: "had so far been" should be "have so far been" Really? i.e., they are now in the public domain (that's why I used past tense). -- (sorry, English as second language here) > Section 1, fourth para: The techniques could *probably* be exploited. > And maybe mention DHCPv6 here as well...? Not quite "probably". They *are* effective against rafixd and others.... > Section 2.1, first sentence is missing words or something. No legitimate > what? Fixed. ("no legitimate use") > Section 2.1 first para: should be "simply ignoring". Suggest leaving > "simple", "simply" etc out of such sentences. It might not be simple at > all. I was referring to end-system implementations (rather than RA-Guard or the like), and thus in that case it *is* simple. The text now reads: "While there is currently no legitimate use for IPv6 Extension Headers in ICMPv6 Router Advertisement messages, Neighbor Discovery implementations allow the use of Extension Headers included in these messages, by simply ignoring the received options." Please let me know if it looks okay now. > Section 2.1 second para: should be "implement" not "implements" Fixed. > Page 6: This might be a silly thought, but why would the implementation > need to do fragment reassembly? All it needs to do is locate RAs, > whether they are in fragments or not. That's the point. See the figure in Page 6: How could an RA-Guard implementation locate the RA in the second fragment without performing fragment reassembly? > It has all the info it needs in > the fragment with the RA. Not at all. All it can tell from that fragment is that the original IPv6 packet (prior to fragmentation) contained a Destination Options header. Since the length of that Destination Options header cannot be inferred from the second fragment, it is impossible to locate de RA. -- Not even to tell that the packet actually is an RA! > That is, it passes earlier packets, but if a > fragment arrives with an RA in it, it checks the RA. The destination > might end up with a partial packet, but it will never get the damaging > fragment, and will eventually discard the partial. Please see above. -- and also let me know if you think that this should be clarified or additional text should be added. > PS: Responding on this list, rather than NANOG - is that OK? Excellent! 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 farmer@umn.edu Wed Jun 1 22:14:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE53BE0711 for ; Wed, 1 Jun 2011 22:14:41 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wt-6iIYSwmPl for ; Wed, 1 Jun 2011 22:14:41 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 08D72E06FE for ; Wed, 1 Jun 2011 22:14:40 -0700 (PDT) Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 2 Jun 2011 00:14:34 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-iy0-f171.google.com [209.85.210.171] #+LO+TR X-Umn-Classification: local Received: by iyi20 with SMTP id 20so623138iyi.16 for ; Wed, 01 Jun 2011 22:14:34 -0700 (PDT) Received: by 10.42.144.200 with SMTP id c8mr661762icv.463.1306991673960; Wed, 01 Jun 2011 22:14:33 -0700 (PDT) Received: from oit200959392.local (c-24-118-200-23.hsd1.mn.comcast.net [24.118.200.23]) by mx.google.com with ESMTPS id ex14sm49345icb.1.2011.06.01.22.14.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 22:14:32 -0700 (PDT) Message-ID: <4DE71C36.4070500@umn.edu> Date: Thu, 02 Jun 2011 00:14:30 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Fernando Gont References: <4DE674CC.2000402@gont.com.ar> <1306974972.5839.185.camel@karl> <4DE6E465.9040804@gont.com.ar> In-Reply-To: <4DE6E465.9040804@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Karl Auer , IPv6 Operations Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 05:14:41 -0000 Fernando, Excellent draft and some important research, you and Karl covered a number of issues I noticed as well. However, I have an additional comment; While this is an important attack vector, and must be mitigated, and I agree that draft-gont-6man-nd-extension-headers seems like the best way to accomplish that in the long-term. Nevertheless, it should also be noted in this draft that while many current RA-Guard implementation are vulnerable to these attack vectors, such implementations are still useful and an effective means of mitigating several misconfiguration issues detrimental to the operation of a large number IPv6 networks. Put another way, many IPv6 networks are still better off implementing RA-Guard with these vulnerabilities, then not implementing GA-Guard at all. On 6/1/11 20:16 CDT, Fernando Gont wrote: > Hi, Karl, > > Thanks so much for your feedback. (I've removed 6man from the > recipients, and have added v6ops which is the wg at which this draft is > aimed). > > On 06/01/2011 09:36 PM, Karl Auer wrote: >> On Wed, 2011-06-01 at 14:20 -0300, Fernando Gont wrote: >>> * "IPv6 Router Advertisement Guard (RA-Guard) Evasion", available at: >>> http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt >> >> Section 1, second para: "of identifying" should be "to identify" > > Done. > > >> Section 1, third para: "had so far been" should be "have so far been" > > Really? i.e., they are now in the public domain (that's why I used past > tense). -- (sorry, English as second language here) > > > >> Section 1, fourth para: The techniques could *probably* be exploited. >> And maybe mention DHCPv6 here as well...? > > Not quite "probably". They *are* effective against rafixd and others.... > > > >> Section 2.1, first sentence is missing words or something. No legitimate >> what? > > Fixed. ("no legitimate use") > > > >> Section 2.1 first para: should be "simply ignoring". Suggest leaving >> "simple", "simply" etc out of such sentences. It might not be simple at >> all. > > I was referring to end-system implementations (rather than RA-Guard or > the like), and thus in that case it *is* simple. > > The text now reads: > "While there is currently no legitimate use for IPv6 Extension Headers > in ICMPv6 Router Advertisement messages, Neighbor Discovery > implementations allow the use of Extension Headers included in these > messages, by simply ignoring the received options." > > Please let me know if it looks okay now. > > >> Section 2.1 second para: should be "implement" not "implements" > > Fixed. > > >> Page 6: This might be a silly thought, but why would the implementation >> need to do fragment reassembly? All it needs to do is locate RAs, >> whether they are in fragments or not. > > That's the point. See the figure in Page 6: How could an RA-Guard > implementation locate the RA in the second fragment without performing > fragment reassembly? > > >> It has all the info it needs in >> the fragment with the RA. > > Not at all. All it can tell from that fragment is that the original IPv6 > packet (prior to fragmentation) contained a Destination Options header. > Since the length of that Destination Options header cannot be inferred > from the second fragment, it is impossible to locate de RA. -- Not even > to tell that the packet actually is an RA! > > >> That is, it passes earlier packets, but if a >> fragment arrives with an RA in it, it checks the RA. The destination >> might end up with a partial packet, but it will never get the damaging >> fragment, and will eventually discard the partial. > > Please see above. -- and also let me know if you think that this should > be clarified or additional text should be added. > > >> PS: Responding on this list, rather than NANOG - is that OK? > > Excellent! > > Thanks! > > Best regards, -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From fernando.gont.netbook.win@gmail.com Wed Jun 1 23:46:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15B7E07AC for ; Wed, 1 Jun 2011 23:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kwyfZSyEYL1 for ; Wed, 1 Jun 2011 23:46:28 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAF2E072E for ; Wed, 1 Jun 2011 23:46:28 -0700 (PDT) Received: by gwb20 with SMTP id 20so289218gwb.31 for ; Wed, 01 Jun 2011 23:46:27 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=G/3uvWtnJ4vxpxHXoJbK3s9vzDANHas6xCfj6rwvNEg=; b=Byq6h0/7hSt2aHS5Bi9C5ObsQoYr1TeLkc0HYqLwz3rIus8AO67Zzv2crZwqU2QS52 R2BYN252P1GqMWqLiku9X3SmpMaIYSzovO+dV7hccK4JqFMJvytNPzlRvwUwrhFQ+y+S 9qIcR58+2TFTSAUNgeBha+4MinesJp/R964Hw= 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:content-type :content-transfer-encoding; b=HEmuY3wknRV05qEe5wXydwEVeMKJvhxI86wM/Wa4BtvzC+UNNEXLGbvpd4iYdSGwl2 fXu48HcvKiNAJYUja+2IY4PY2EQik0yPeG7okL4guQCvnblkVJFkdtGuNKcJYu0S/ULL 6buOwrfQQfNkBAf7OSMie2b+b3J4Pzo4TyGWU= Received: by 10.101.179.5 with SMTP id g5mr198260anp.117.1306997187616; Wed, 01 Jun 2011 23:46:27 -0700 (PDT) Received: from [192.168.123.103] ([190.48.221.55]) by mx.google.com with ESMTPS id j3sm231992anm.39.2011.06.01.23.46.23 (version=SSLv3 cipher=OTHER); Wed, 01 Jun 2011 23:46:26 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DE731B9.2080605@gont.com.ar> Date: Thu, 02 Jun 2011 03:46:17 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: David Farmer References: <4DE674CC.2000402@gont.com.ar> <1306974972.5839.185.camel@karl> <4DE6E465.9040804@gont.com.ar> <4DE71C36.4070500@umn.edu> In-Reply-To: <4DE71C36.4070500@umn.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Karl Auer , IPv6 Operations Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 06:46:29 -0000 Hi, David, Thanks so much for your comments! - Please find my responses inline... On 06/02/2011 02:14 AM, David Farmer wrote: > While this is an important attack vector, and must be mitigated, and I > agree that draft-gont-6man-nd-extension-headers seems like the best way > to accomplish that in the long-term. Nevertheless, it should also be > noted in this draft that while many current RA-Guard implementation are > vulnerable to these attack vectors, such implementations are still > useful and an effective means of mitigating several misconfiguration > issues detrimental to the operation of a large number IPv6 networks. > > Put another way, many IPv6 networks are still better off implementing > RA-Guard with these vulnerabilities, then not implementing GA-Guard at all. Agreed. In which section do you think I should add some text along these lines? 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 arturo.servin@gmail.com Thu Jun 2 05:52:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A7BE09A6 for ; Thu, 2 Jun 2011 05:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjQ4wZPP9GhO for ; Thu, 2 Jun 2011 05:52:48 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81F06E0A3F for ; Thu, 2 Jun 2011 05:52:30 -0700 (PDT) Received: by yxk30 with SMTP id 30so404886yxk.31 for ; Thu, 02 Jun 2011 05:52:30 -0700 (PDT) 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=FarvYtZyX/X0li/TZsHojMwx7QUmkYBjLWUaPsVEoHA=; b=QbZjISa3KDoF378MWW59xEvRayemZW8h6vYYolvsCqi2EcC0ge9OUUgYTEo/onsa2O diyJ874L11wzzHWnoXhoTVpKwFPSfxRLMeh4P4x7lprYX1WraSAPYdkVTh1+XkNdreK3 0wbBxi2hy8RViBSsdLSLu03z0kh3mZcQ6iTts= 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=Ab5OMA/2osSSblYG5qdQtsn3+CLyMlS+DCw5FlfLP9OUEpKkh9Wtwj60x6G+ziiWYG dvoUSwXh57x+7QKg+ZX1Vi7FMuCJyBO6gXSDmGqIRCmu3qVnqKM3ThNMXWcRPL8ZcyAe /Bw2j+4ut3SvcJ7PDdoTvjuJMxSJv06DTRoW8= Received: by 10.236.79.5 with SMTP id h5mr794064yhe.468.1307019149703; Thu, 02 Jun 2011 05:52:29 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy ([200.7.85.188]) by mx.google.com with ESMTPS id o45sm382902yhk.35.2011.06.02.05.52.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2011 05:52:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <4DE731B9.2080605@gont.com.ar> Date: Thu, 2 Jun 2011 09:52:23 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <83262CF6-B6B2-45AA-8203-6216AEB3BFF4@gmail.com> References: <4DE674CC.2000402@gont.com.ar> <1306974972.5839.185.camel@karl> <4DE6E465.9040804@gont.com.ar> <4DE71C36.4070500@umn.edu> <4DE731B9.2080605@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 12:52:50 -0000 Fernando, I agree with David. At least for me, 100% of the identified = attacks (excepting your demo the other day) have been because of a = missconfigured host and ramond has been very useful. I think important = to note that even though complex attacks are possible, current mechanism = are useful and recommended to use instead of "nothing at all". May be in the "introduction" or in "other implications" you = could add the text. regards, .as On 2 Jun 2011, at 03:46, Fernando Gont wrote: > Hi, David, >=20 > Thanks so much for your comments! - Please find my responses inline... >=20 > On 06/02/2011 02:14 AM, David Farmer wrote: >> While this is an important attack vector, and must be mitigated, and = I >> agree that draft-gont-6man-nd-extension-headers seems like the best = way >> to accomplish that in the long-term. Nevertheless, it should also be >> noted in this draft that while many current RA-Guard implementation = are >> vulnerable to these attack vectors, such implementations are still >> useful and an effective means of mitigating several misconfiguration >> issues detrimental to the operation of a large number IPv6 networks. >>=20 >> Put another way, many IPv6 networks are still better off implementing >> RA-Guard with these vulnerabilities, then not implementing GA-Guard = at all. >=20 > Agreed. In which section do you think I should add some text along = these > lines? >=20 > Thanks! >=20 > Best regards, > --=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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Thu Jun 2 09:30:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C8CE07A2 for ; Thu, 2 Jun 2011 09:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.435 X-Spam-Level: X-Spam-Status: No, score=-106.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtS53CIZagPh for ; Thu, 2 Jun 2011 09:30:57 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACB8E079A for ; Thu, 2 Jun 2011 09:30:57 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LM6007M08HXA3B3@mail-out.apple.com> for v6ops@ietf.org; Thu, 02 Jun 2011 09:30:35 -0700 (PDT) X-AuditID: 11807134-b7c00ae0000074fb-10-4de7baabf3bc Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id E8.06.29947.BAAB7ED4; Thu, 02 Jun 2011 09:30:35 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LM6000M18IZ5X70@cardamom.apple.com> for v6ops@ietf.org; Thu, 02 Jun 2011 09:30:35 -0700 (PDT) From: james woodyatt In-reply-to: <4DE6DD93.507@gont.com.ar> Date: Thu, 02 Jun 2011 09:30:35 -0700 Message-id: References: <4DE6DD93.507@gont.com.ar> To: IPv6 Operations X-Mailer: Apple Mail (2.1237) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 16:30:59 -0000 everyone-- What if the list of More Specific Route options is large enough that they won't all fit in a single Router Advertisement message? -- james woodyatt member of technical staff, core os networking From fernando.gont.netbook.win@gmail.com Thu Jun 2 11:36:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33217E0801 for ; Thu, 2 Jun 2011 11:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yxi-80OaM9qV for ; Thu, 2 Jun 2011 11:36:11 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8318CE07E6 for ; Thu, 2 Jun 2011 11:36:11 -0700 (PDT) Received: by ywp31 with SMTP id 31so586420ywp.31 for ; Thu, 02 Jun 2011 11:36:11 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=CtJ6tFxU5xbqNBW0r4WReN1qoAaeqxEySvSdEx1eozw=; b=MbkD6uszKXk7PSrnFq57L3uKAFWbE71TVCH92aYoTHSvYcNuZUp/23tJZNxBM1+RLd OlriT+3lbtaxn89duSgtn4l0/vRd1iIEDfAOncDCT3do/PfmiP5U4/7M4cJCvK87o0x5 eMmEKH2qjOdaxpF2xPzPJFf/FLLsH2WR4e4QM= 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:content-type :content-transfer-encoding; b=xgMCwW190XDXftsyKGrMZwAB+zVjw7/L+5U8+dO5Kau7TZjos7VVhvrb4RmxB4RpXV oUYE8uH4T6LPPIVZnatX6Wm21nBHR7rYwVtWH6PtiyQqcRR2ofFmiOfB8Wh2XrMsWxKs IPyKPmFiOxIG4oEEawg85eJdYnvIYvqb8ldcw= Received: by 10.91.39.14 with SMTP id r14mr1033322agj.135.1307039771045; Thu, 02 Jun 2011 11:36:11 -0700 (PDT) Received: from [192.168.123.103] ([190.48.242.248]) by mx.google.com with ESMTPS id j5sm598303ani.31.2011.06.02.11.36.08 (version=SSLv3 cipher=OTHER); Thu, 02 Jun 2011 11:36:10 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DE7D813.3050700@gont.com.ar> Date: Thu, 02 Jun 2011 15:36:03 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: james woodyatt References: <4DE6DD93.507@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 18:36:12 -0000 James, On 06/02/2011 01:30 PM, james woodyatt wrote: > everyone-- > > What if the list of More Specific Route options is large enough that they won't all fit in a single Router Advertisement message? You send them in separate RAs. 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 jhw@apple.com Thu Jun 2 11:49:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E82DE087B for ; Thu, 2 Jun 2011 11:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.455 X-Spam-Level: X-Spam-Status: No, score=-106.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpuiFDgd6de7 for ; Thu, 2 Jun 2011 11:49:50 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id EAEACE0879 for ; Thu, 2 Jun 2011 11:49:49 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LM600EZFEZ1ISE0@mail-out.apple.com> for v6ops@ietf.org; Thu, 02 Jun 2011 11:49:49 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-12-4de7db4a0401 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id E9.A6.18996.B4BD7ED4; Thu, 02 Jun 2011 11:49:47 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LM600BCBEYYT520@cardamom.apple.com> for v6ops@ietf.org; Thu, 02 Jun 2011 11:49:46 -0700 (PDT) From: james woodyatt In-reply-to: <4DE7D813.3050700@gont.com.ar> Date: Thu, 02 Jun 2011 11:49:46 -0700 Message-id: <54B74260-345E-4F90-A45D-3545062625DF@apple.com> References: <4DE6DD93.507@gont.com.ar> <4DE7D813.3050700@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1237) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Operations Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 18:49:50 -0000 On Jun 2, 2011, at 11:36 , Fernando Gont wrote: > > You send them in separate RAs. A less aggressive alternative solution would permit Router Advertisement messages to be fragmented but to simply require the whole ICMPv6 header to be present in the initial fragment of the message and require the RA Guard to follow the extension header chain properly all the way to the ICMPv6 header. -- james woodyatt member of technical staff, core os networking From behcetsarikaya@yahoo.com Thu Jun 2 11:52:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8AAE0883 for ; Thu, 2 Jun 2011 11:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n4X+ManfAg3 for ; Thu, 2 Jun 2011 11:52:43 -0700 (PDT) Received: from nm12.bullet.mail.sp2.yahoo.com (nm12.bullet.mail.sp2.yahoo.com [98.139.91.82]) by ietfa.amsl.com (Postfix) with SMTP id B0E25E0880 for ; Thu, 2 Jun 2011 11:52:43 -0700 (PDT) Received: from [98.139.91.66] by nm12.bullet.mail.sp2.yahoo.com with NNFMP; 02 Jun 2011 18:52:39 -0000 Received: from [98.139.91.44] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 02 Jun 2011 18:52:39 -0000 Received: from [127.0.0.1] by omp1044.mail.sp2.yahoo.com with NNFMP; 02 Jun 2011 18:52:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 806280.85715.bm@omp1044.mail.sp2.yahoo.com Received: (qmail 98584 invoked by uid 60001); 2 Jun 2011 18:52:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307040759; bh=G75Jn69Qa57+M5HByPpFdF0hGc0gPXGyMNQnzcBBhWY=; 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=fuiEiEk2BhNcxnvckOgml9GEL+RXlLbDL6EORVhpvcv0trdqgt2/87LkWPBG5AsMPvs/KU3ruPxiNh1JbxDD5MMF9+A0HXyolgxyGUaUBMCfWzN5jLDwC2BjVMWY/Ld5EF+3EoHCerz/CBO2hVpERK8ufA6bp9pemEONC+TpdUA= 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=RdOTOPUX8pbTX2kD3ANxinerBUo28anbDau6i62IXA6/PQnC10UbYmq560DLdcoGrvGdn/DRDEVZGKY250L0z/RKBzXMmG29+2T0qfPT5e0NUl/qPx7OvC9R8zO+tXM+unheHy+smJHa8tUdzvDXCwtR7B8W796FquimBguN3Eo=; Message-ID: <292812.75847.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: M1V0jAsVM1nIMiGSwF2CIaYgq9n6qRrEM8yjd.WdCm6RxqI 1pcrEdnrLaaX6scjrpXzWdQmnggf8P9HJ5DcKckiVaqDTbXhFdusB0aNplpv EuUMKL4Hsu4YOw5YuB3yr0myvK2epRDwdTvYEX8L1Qlo1c5rtRlCtNxHgy8P frXxzqt9kwfEUTx5Tp7be_RTDowoz3N6bLZn.NNnueh9FIdmvRntpPd43w_9 2BTj.X5X_6IS3KPwA1Sm8vdJHKTkx_uVTlEV6HH25O0RBqbweykNdGq.LJIB 7rMgq966P6PrMIHuMbbgzoDBFJLuCWO35OB0kKDHFIDlKxIcvbunulITHHxo nZVuyfgyTkak0elcBgPfM5uiWeaOd1TSGCs.iC9bWvS.c3MTmre_snB2w6be I2J_tqfz_nNhf8PRUS6TI20yTMu.Sa11x3aJVUBC7iwdPFRq4TqGxAg9tJwV Bt25SD3uVkFcYhfqoYYx04Hc5Rg-- Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Thu, 02 Jun 2011 11:52:39 PDT X-Mailer: YahooMailRC/570 YahooMailWebService/0.8.111.304355 References: <449804.6587.qm@web111416.mail.gq1.yahoo.com> <2960D350-CDE4-4545-8798-48B110EDD601@gmail.com> <785331.40680.qm@web111404.mail.gq1.yahoo.com> <7511052D-17D3-46AA-867D-52195553B16B@gmail.com> <589777.33995.qm@web111415.mail.gq1.yahoo.com> Date: Thu, 2 Jun 2011 11:52:39 -0700 (PDT) From: Behcet Sarikaya To: Cameron Byrne In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IPv6 Operations Subject: Re: [v6ops] New Version Notification for draft-sarikaya-v6ops-prefix-delegation-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jun 2011 18:52:44 -0000 Hi Cameron, > On Wed, Jun 1, 2011 at 11:33 AM, Behcet Sarikaya > wrote: > > Hi Jouni, > > This draft is an IETF draft. I think that discussing what should be done >with > > 3GPP, another SDO is out of scope. If you started the exclude thing in 3GPP, > > good for you. But what counts is, it is now an IETF draft. > > > > There is a coordination between the IETF and 3GPP outlined in > > http://tools.ietf.org/html/rfc3113 > > While there is not much detail about the relationship there, my > understanding is that IETF makes the protocols and 3GPP makes the > architecture. 3GPP SA2 makes Stage 2 documents which are essentially architecture. But 3GPP SA3 works on Stage 3 documents which are the protocol solutions. So 3GPP makes both architecture and protocol, not just architecture, having said that I don't understand what is the point here? > I believe the document in discussion here is an > architecture since it does not specify a new protocol (AFAIK). > Therefore, i think the ideas here are better fit for 3GPP. Pls. look at v6ops WG documents like draft-ietf-v6ops-v6-in-mobile-networks and draft-ietf-v6ops-3gpp-eps, etc. Are they defining new protocols? They are tutorials. draft-sarikaya-v6ops-prefix-delegation is of similar kind. It is describing how DHCPv6 PD can be used in mobile networks like 3GPP. > > > Many people expressed positive opinions on > > draft-sarikaya-v6ops-prefix-delegation so far. All reviews have been taken >care > > of. > > While i work at a mobile network, i cannot really understand this > draft and what it is trying to achieve clearly. My confusion starts > with Figure 1, which does not look like any GSM/UMTS/LTE network that > i have ever seen ... although there is some text that says an access > router (AR) is a PDN .... I still do not really recognize it. > Possibly this is my fault. It appears this draft just explains how > DHCPv6 works at a high level where a PDN talks to a DHCPv6 server and > then relays that info as an RA.... If that is all, and I have not > missed something, i do not think this draft adds much value. Well that is Sec. 3.1. Then there is Sec. 3.2 and 3.3 and so on, pls continue to read. > > I believe DHCP-PD is clearly defined at a 3GPP Release 10 feature, if > i remember correctly.... so it is already being defined there. Not sure which specific document you're referring to. If it is being defined then draft-sarikaya-v6ops-prefix-delegation will be useful to them. This is inline with v6ops charter. I am disappointed with the negativity in this mail which is unusual to this author. I was expecting a review that would lead to revision -06 but could not find anything to change. Regards, Behcet From iesg-secretary@ietf.org Thu Jun 2 12:01:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAE3E089F; Thu, 2 Jun 2011 12:01:49 -0700 (PDT) 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.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wuj9Ulo-appl; Thu, 2 Jun 2011 12:01:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82531E0879; Thu, 2 Jun 2011 12:01:24 -0700 (PDT) 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.55 Message-ID: <20110602190124.11380.95218.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2011 12:01:24 -0700 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Advisory Guidelines for 6to4 Deployment) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 19:01:49 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Advisory Guidelines for 6to4 Deployment' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides advice to network operators about deployment of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It is principally addressed to Internet Service Providers, including those that do not yet support IPv6, and to Content Providers. Some advice to implementers is also included. The intention of the advice is to minimise both user dissatisfaction and help desk calls. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-advisory/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-advisory/ No IPR declarations have been submitted directly on this I-D. From narten@us.ibm.com Thu Jun 2 12:39:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48012E089C for ; Thu, 2 Jun 2011 12:39:47 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKddGZFgPpue for ; Thu, 2 Jun 2011 12:39:46 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id BCCEBE089A for ; Thu, 2 Jun 2011 12:39:46 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p52JaX3X030170 for ; Thu, 2 Jun 2011 13:36:33 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p52JdJ1f133924 for ; Thu, 2 Jun 2011 13:39:23 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p52DcnaK030401 for ; Thu, 2 Jun 2011 07:38:51 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-48-35-109.mts.ibm.com [9.48.35.109]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p52DckTo030251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2011 07:38:47 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p52Jd8rI002414; Thu, 2 Jun 2011 15:39:12 -0400 Message-Id: <201106021939.p52Jd8rI002414@cichlid.raleigh.ibm.com> To: Fernando Gont In-reply-to: <4DE7D813.3050700@gont.com.ar> References: <4DE6DD93.507@gont.com.ar> <4DE7D813.3050700@gont.com.ar> Comments: In-reply-to Fernando Gont message dated "Thu, 02 Jun 2011 15:36:03 -0300." Date: Thu, 02 Jun 2011 15:39:08 -0400 From: Thomas Narten Cc: IPv6 Operations Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 19:39:47 -0000 > > What if the list of More Specific Route options is large enough that they won't all fit in a single Router Advertisement message? > You send them in separate RAs. Right. You fragment at the transport layer. That said, I am not at all convinced that we should outlaw the use of fragmentation for ND. RA-Guard is not a perfect solution to RA spoofing. It never will be. It has limitations (and always will). ND packets that using extension headers or fragmentation are just one specific example. Thomas From fernando.gont.netbook.win@gmail.com Thu Jun 2 13:46:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45282E0846 for ; Thu, 2 Jun 2011 13:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0S83tOo6hY1 for ; Thu, 2 Jun 2011 13:46:19 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1A3DE07E4 for ; Thu, 2 Jun 2011 13:46:19 -0700 (PDT) Received: by yic13 with SMTP id 13so652483yic.31 for ; Thu, 02 Jun 2011 13:46:19 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=Glfq3IauhpX1GFp7Cf1+an2knAe0c5pKzk8WO5atSQA=; b=eAKPZT4O4r8nN4cHPE05SlqorWl5xsnD/8YEwGzRsSr2iZkJacKrKXZLBCUIagC8jE kUUKCidRokkAbdu8hPxt7z97DrsM6mOkkmjA7fFrYQlWvvz9ohxujBLjnrAhQIOyODML J7MwJ0IPtF1o9zaHB9JBk29OW6QZE3z8e5o+4= 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:content-type :content-transfer-encoding; b=cAalqUP+OSidD31PzfU8EJAoyUvD3NdkdUmYDyXUOMIHyLMxQWwTadfS8sCNEE76fn kL2BbOPRGivelyCbO466RyEuaHzXVv24I/jrioFDv/oPAEpx6nRYVtlJQhr0NdEZ8ffS nyHQkB0KYrc4lL6s+NMsHQDT37P8e4M377E5o= Received: by 10.101.111.10 with SMTP id o10mr787916anm.143.1307047578894; Thu, 02 Jun 2011 13:46:18 -0700 (PDT) Received: from [192.168.123.100] ([190.48.242.248]) by mx.google.com with ESMTPS id o6sm673870ank.42.2011.06.02.13.46.15 (version=SSLv3 cipher=OTHER); Thu, 02 Jun 2011 13:46:17 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DE7F695.5040004@gont.com.ar> Date: Thu, 02 Jun 2011 17:46:13 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Thomas Narten References: <4DE6DD93.507@gont.com.ar> <4DE7D813.3050700@gont.com.ar> <201106021939.p52Jd8rI002414@cichlid.raleigh.ibm.com> In-Reply-To: <201106021939.p52Jd8rI002414@cichlid.raleigh.ibm.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 20:46:20 -0000 Hi, Thomas, On 06/02/2011 04:39 PM, Thomas Narten wrote: >> You send them in separate RAs. > > Right. You fragment at the transport layer. Isn't this even suggested by the existing specs, btw? > That said, I am not at all convinced that we should outlaw the use > of fragmentation for ND. So far the only updates to SLAAC seem to be in the area of new options (e.g. RDNSS), and nothing that requires fragmentation (or that couldn't be addresses by "fragmenting at the transport layer", as you indicate). Outlawing the use of fragmentation for ND -- particularly when there's no legitimate use for it, and doesn't look like there's going to be -- allows IPv6 network to match the security level to the IPv4 counterpart (where, as a result of the limited header length, you can always successfully enforce an IPv4-version of the RA-Guard mitigation). > RA-Guard is not a perfect solution to RA spoofing. It never will be. > It has limitations (and always will). ND packets that using extension > headers or fragmentation are just one specific example. Can you think of any other way to circumvent RA-Guard (when extension headers are outlawed for ND)? 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 fernando.gont.netbook.win@gmail.com Thu Jun 2 13:53:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910DEE08C5 for ; Thu, 2 Jun 2011 13:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH7JHBkw9-CY for ; Thu, 2 Jun 2011 13:53:53 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id EFF0AE07F3 for ; Thu, 2 Jun 2011 13:53:52 -0700 (PDT) Received: by ywp31 with SMTP id 31so654448ywp.31 for ; Thu, 02 Jun 2011 13:53:52 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=h72yOm5jbhNdXMKe80Di6YiyVHe2UvZfTNODShIAQOM=; b=OcB6Esp5xgMC+e/k7E77vJyiaMrvOkQTfbnt3bZauaPhNAkTzGkVEII8u6ifBVs0Ly wGmbUqlNNfpa2HueHHIzkOf/ChMkuBCFnoSoA1fTfqsSybURg3xmHUtGDDpMycq8BNvE KBDVPChz96fuxsM5f5D7K/dezg+wzIhza/2dQ= 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:content-type :content-transfer-encoding; b=bhO21PPXPa3W8IaFFX86b84OB6S/0CjLsIoJwhGHIz7VWBZpVs6vLOhgcq0GVE0+/b 2ZpoItGjb2lGe8rjHFDdSe+B0915JWnqJFtZnhKtpHIaDpzz/ntxU3KWXT48IxjwWlpj 3KTdbs6BGM3yAG5z4FHg824HokkfK1PPAdSt4= Received: by 10.91.5.40 with SMTP id h40mr1141100agi.106.1307048032416; Thu, 02 Jun 2011 13:53:52 -0700 (PDT) Received: from [192.168.123.100] ([190.48.242.248]) by mx.google.com with ESMTPS id 10sm679931anw.23.2011.06.02.13.53.50 (version=SSLv3 cipher=OTHER); Thu, 02 Jun 2011 13:53:51 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DE7F85B.6060509@gont.com.ar> Date: Thu, 02 Jun 2011 17:53:47 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: james woodyatt References: <4DE6DD93.507@gont.com.ar> <4DE7D813.3050700@gont.com.ar> <54B74260-345E-4F90-A45D-3545062625DF@apple.com> In-Reply-To: <54B74260-345E-4F90-A45D-3545062625DF@apple.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 20:53:53 -0000 Hi, James, On 06/02/2011 03:49 PM, james woodyatt wrote: >> You send them in separate RAs. > > A less aggressive alternative solution would permit Router > Advertisement messages to be fragmented but to simply require the > whole ICMPv6 header to be present in the initial fragment of the > message and require the RA Guard to follow the extension header chain > properly all the way to the ICMPv6 header. Then you open the door to an attacker sending a packet with multiple instances of different extension headers, requiring RA-Guard to follow the packet chain, which could not only be expensive, but maybe not even possible. I'd keep it simple, particularly when there's no real motivation for the converse, and when the proposal in draft-gont-6man-nd-extension-headers would make it possible for the v6 countermeasures to be as simple as the v4 counterpart... Thoughts? 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 pch-b2B3A6689@u-1.phicoh.com Thu Jun 2 14:10:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34ADE08B7 for ; Thu, 2 Jun 2011 14:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRUDRq+Jousq for ; Thu, 2 Jun 2011 14:10:19 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA66E08B2 for ; Thu, 2 Jun 2011 14:10:17 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QSF9c-0001VXC; Thu, 2 Jun 2011 23:10:08 +0200 Message-Id: To: james woodyatt From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <4DE6DD93.507@gont.com.ar> <4DE7D813.3050700@gont.com.ar> <54B74260-345E-4F90-A45D-3545062625DF@apple.com> In-reply-to: Your message of "Thu, 02 Jun 2011 11:49:46 -0700 ." <54B74260-345E-4F90-A45D-3545062625DF@apple.com> Date: Thu, 02 Jun 2011 23:09:53 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:10:19 -0000 In your letter dated Thu, 02 Jun 2011 11:49:46 -0700 you wrote: >On Jun 2, 2011, at 11:36 , Fernando Gont wrote: >> >> You send them in separate RAs. > >A less aggressive alternative solution would permit Router Advertisement messa >ges to be fragmented but to simply require the whole ICMPv6 header to be prese >nt in the initial fragment of the message and require the RA Guard to follow t >he extension header chain properly all the way to the ICMPv6 header. Given that it is L2 devices that have to filter ND messages, it is important to keep them as simple as possible. I would suggest to disallow any extension headers unless we can find a clear case where they are required. And then allow any IPv6-over-foo document to define additional extension headers for that particular medium. From fernando.gont.netbook.win@gmail.com Thu Jun 2 15:48:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16D7E0899 for ; Thu, 2 Jun 2011 15:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTomlbvv5Kfw for ; Thu, 2 Jun 2011 15:48:00 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E126BE0879 for ; Thu, 2 Jun 2011 15:47:59 -0700 (PDT) Received: by gxk19 with SMTP id 19so693520gxk.31 for ; Thu, 02 Jun 2011 15:47:59 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=n3gDfPbRvonapvhFlnetUO/cPl7U4LAbpkqKxwTfgfI=; b=QK1mrFScqAkWw3vvfeUX4VsfRfnq5wQ8S4tNBF634JNeBz7NRNm7owm1IjtYAJxYcs GJkKL0KWSCH9c8Pkeo1rOCIYX1pKR7TAA+oX5Ci97QR0aR6lMk1wgjWpcQabYrOTre7J xzzQaPdp4n+w4IVCUlKWa3VJ95gUpCFGqzYcA= 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:content-type :content-transfer-encoding; b=EgjP4ort2vyM1UZ2b/vqwF52upgUfPzGstmZ9ecop1+aDnZbbPKI0X/firrf1paCvp ckQy/adz0ZV85Jy5cCuWBdb47k/EFH2FYyOLkKEPhr+ZUjzN479GqlNzcYR8HfhjbyG5 y+ljyeoKsXLWYIjvYaUrUR54/jv7aPrdA8gm8= Received: by 10.101.214.10 with SMTP id r10mr875418anq.75.1307054879054; Thu, 02 Jun 2011 15:47:59 -0700 (PDT) Received: from [192.168.1.113] ([190.190.102.237]) by mx.google.com with ESMTPS id c35sm740935anp.37.2011.06.02.15.47.56 (version=SSLv3 cipher=OTHER); Thu, 02 Jun 2011 15:47:58 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DE7DF8F.7080708@gont.com.ar> Date: Thu, 02 Jun 2011 16:07:59 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: james woodyatt References: <4DE6DD93.507@gont.com.ar> <4DE7D813.3050700@gont.com.ar> In-Reply-To: <4DE7D813.3050700@gont.com.ar> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 22:48:00 -0000 John, On 06/02/2011 03:36 PM, Fernando Gont wrote: > James, > > On 06/02/2011 01:30 PM, james woodyatt wrote: >> everyone-- >> >> What if the list of More Specific Route options is large enough that they won't all fit in a single Router Advertisement message? > > You send them in separate RAs. By the way, I thought this was already implied from the current specifications... But please do let me know if you think this should be clarified. 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 Fred.L.Templin@boeing.com Fri Jun 3 08:14:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D90E06F7 for ; Fri, 3 Jun 2011 08:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.091 X-Spam-Level: X-Spam-Status: No, score=-6.091 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFYh-uFgk5GJ for ; Fri, 3 Jun 2011 08:14:02 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBC0E06E9 for ; Fri, 3 Jun 2011 08:14:02 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p53FDs1h014208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 3 Jun 2011 08:13:54 -0700 (PDT) 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 p53FDriA010372 for ; Fri, 3 Jun 2011 10:13:53 -0500 (CDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p53FDqrg010345 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Fri, 3 Jun 2011 10:13:53 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Fri, 3 Jun 2011 08:13:52 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" Date: Fri, 3 Jun 2011 08:13:51 -0700 Thread-Topic: 'draft-templin-v6ops-isops' as v6ops wg item? Thread-Index: AcwgpyINWzmho1jhTSCalqDOZu75JQBWS/WQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 15:14:03 -0000 Hello, Significant improvements have been made to this document (below) based on comments received and new observations. IMHO, this is an important document for enabling transition to IPv6 within IPv4 sites; hence, I would like to call for working group adoption at this time. Thanks - Fred fred.l.templin@boeing.com -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Wednesday, June 01, 2011 2:59 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-v6ops-isops-10.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Operational Guidance for IPv6 Deployment in IPv4 Sites u= sing ISATAP Author(s) : Fred L. Templin Filename : draft-templin-v6ops-isops-10.txt Pages : 27 Date : 2011-06-01 Many end user sites in the Internet today still have predominantly IPv4 internal infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 continues to provide satisfactory internal routing and addressing services for most applications. As more and more IPv6-only services are deployed in the Internet, however, end user devices within such sites will increasingly require at least basic IPv6 functionality for external access. It is also expected that more and more IPv6-only devices will be deployed within the site over time. This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-templin-v6ops-isops-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-templin-v6ops-isops-10.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From stephen.farrell@cs.tcd.ie Sat Jun 4 09:54:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F86E06B9; Sat, 4 Jun 2011 09:54:04 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6gU-EdC3jVT; Sat, 4 Jun 2011 09:54:04 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id E01BAE06B2; Sat, 4 Jun 2011 09:54:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 20B58171D91; Sat, 4 Jun 2011 17:54:00 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1307206438; bh=ZNv1PzZdQgCkhfWeprDHLp+p HqWZY5nSGvhTAoUJvSs=; b=a7/DTDvZUEAVjktgVI++zu/ee6AImye5r7VDKJnY Cy7p6yMMqBbOSSdN8nGdELcTZkIGWRU+cesUJzko6BRFDjX1MiCLHDgPPUTORHCP lGCbyYi4N9IwEGWB5eUt2gjfP4xGGDU7FcmTkyz877ET0Tv1zs7IBY4kuN+SMre0 QJJasZSEr19y8B7cG2hsTd1w1yND4f/+3KdaCX2DcQ1DmMsAE/HDUz5Wz5+/ioIQ r6PQaZQB5nHuLQwmrOxw4889ZVAoHCAyOBIbgXWarHfxypmYrzXQVtQuiOJN3wFo cCltyseGiNyYZ3Ya3ICwZxSx//J91NFCt9vAAPa07doF6Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 71PooJeNHN6f; Sat, 4 Jun 2011 17:53:58 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.54.169]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D391F171C03; Sat, 4 Jun 2011 17:53:55 +0100 (IST) Message-ID: <4DEA6323.4070302@cs.tcd.ie> Date: Sat, 04 Jun 2011 17:53:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "saag@ietf.org" , ipv6@ietf.org, v6ops@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 04 Jun 2011 10:25:09 -0700 Cc: "Turner, Sean P." , Eliot Lear Subject: [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 16:54:04 -0000 Hi all, We received a liaison [1] from ITU-T saying they're planning to start a couple of work items on the security of IPv6. As far as we know, they envisage developing a "technical guideline on deploying IPv6" and "Security Management Guideline for implementation of IPv6 environment in telecommunications organizations." Bear in mind that they're just starting so they know about as much as we would just before a BoF or something like that. I think we'd like to respond to them that that's great, and we'll be interested in their results, but can they *please* come back to us before saying something should be changed so's we can talk about it. If you've comments or ideas on that, please respond to this in the next week. At that point, we'll get some help translating this into liaison-speak (thanks Eliot:-) and send the result to these lists for a quick check before shipping it off to the ITU-T folks. Cheers, S. [1] https://datatracker.ietf.org/liaison/1047/ From john@jlc.net Sat Jun 4 20:10:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC5D11E8088; Sat, 4 Jun 2011 20:10:53 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wHeI-wCxaHm; Sat, 4 Jun 2011 20:10:52 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2F211E8077; Sat, 4 Jun 2011 20:10:46 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id ED3AA33C21; Sat, 4 Jun 2011 23:10:45 -0400 (EDT) Date: Sat, 4 Jun 2011 23:10:45 -0400 From: John Leslie To: Stephen Farrell Message-ID: <20110605031045.GK88250@verdi> References: <4DEA6323.4070302@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DEA6323.4070302@cs.tcd.ie> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Sat, 04 Jun 2011 20:51:32 -0700 Cc: "Turner, Sean P." , v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" , Eliot Lear Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 03:10:53 -0000 Stephen Farrell wrote: > > We received a liaison [1] from ITU-T saying they're > planning to start a couple of work items on the > security of IPv6. As far as we know, they envisage > developing a "technical guideline on deploying IPv6" > and "Security Management Guideline for implementation > of IPv6 environment in telecommunications > organizations." Bear in mind that they're just starting > so they know about as much as we would just before a > BoF or something like that. > > I think we'd like to respond to them that that's great, > and we'll be interested in their results, but can they > *please* come back to us before saying something should > be changed so's we can talk about it. I don't think that's quite right. We should welcome their studying security issues; but I think we need to _strongly_ encourage them to start from draft-ietf-6man-node-req-bis when it becomes an RFC -- since it has _significant_ changes from RFC 4294 (and an ITU-T study based on RFC4294 will be of rather limited value). Furthermore, ITU-T should NOT propose "changes" to IPv6 protocol or the Node Requirements. The language there should talk of documenting security "concerns" or "issues" or whatever term seems neutral enough; and list as the next step exchanging ideas of what "changes" might help. Clearly, ITU-T is entirely justified in publishing recommendations of what level of security-related-trust to place in IPv6 packet forwarding: but any protocol _changes_ are outside their bailiwick. (As an aside, IETF should resist most proposals for change until IPv6 sees widespread deployment -- deploying to a moving target is just TOO risky.) -- John Leslie From fred@cisco.com Sat Jun 4 23:10:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B6E21F849E; Sat, 4 Jun 2011 23:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8H3oCAwa3c5W; Sat, 4 Jun 2011 23:10:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC5921F849C; Sat, 4 Jun 2011 23:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1273; q=dns/txt; s=iport; t=1307254228; x=1308463828; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=E+G5E4waGRozGgDTvx/8cuWzmvINw4JL+cVxXGBxqHY=; b=jkOfpEIAA67lx14v9243aKouM1YKn+9NoHflHuVfQjdB1p68WOFS1f1G GCk6sRNvIM888qaQBInQBiTRY7HfytSMOcbckfZUmNijScA+VIhTFwxra CLxgaPhrNF+nc0v4ckNFRakyJo8MoNOmhyvkyhPsCYrkfWiswIA7l2HSu Q=; X-IronPort-AV: E=Sophos;i="4.65,321,1304294400"; d="scan'208";a="459906997" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 05 Jun 2011 06:10:26 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p556ALrJ003107; Sun, 5 Jun 2011 06:10:26 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sat, 04 Jun 2011 23:10:26 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sat, 04 Jun 2011 23:10:26 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4DEA6323.4070302@cs.tcd.ie> Date: Sat, 4 Jun 2011 23:10:11 -0700 Message-Id: References: <4DEA6323.4070302@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "Turner, Sean P." , v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" , Eliot Lear Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 06:10:28 -0000 On Jun 4, 2011, at 9:53 AM, Stephen Farrell wrote: > I think we'd like to respond to them that that's great, > and we'll be interested in their results, but can they > *please* come back to us before saying something should > be changed so's we can talk about it. That seems like a reasonable proposal.=20 There a, of course, several proposed sets of security guidelines for = IPv6 floating in the breeze. If you want my druthers, I would like to = see a comprehensive security *architecture*. Steve Kent wrote to me last = month, on another topic, saying > I do have a few comments about the discuss of secruity, in general. I = see that you used the CIA model for describing security = requirements/services. Although this is a commonly used model, I find it = inferior to the model that was developed by ISO in the mid 80's (ISO = 7498-2). It might be worthwhile to look at the ISO model he suggests as a = possible starting point.=20 To my mind, anything resembling a security architecture will identify = threats at the physical, link, network (LAN and IP), transport, and = applications layers, and make recommendations for addressing them - and = not start from the premise of a global federated identity, which doesn't = exist.= From tena@huawei.com Sat Jun 4 23:25:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0354111E808C; Sat, 4 Jun 2011 23:25:16 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTTktb-9HJnn; Sat, 4 Jun 2011 23:25:15 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5DB11E8072; Sat, 4 Jun 2011 23:25:15 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMB002S70I0M9@usaga02-in.huawei.com>; Sun, 05 Jun 2011 01:25:13 -0500 (CDT) Received: from TingZousc1 ([10.212.246.21]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMB00KSJ0HW7G@usaga02-in.huawei.com>; Sun, 05 Jun 2011 01:25:12 -0500 (CDT) Date: Sat, 04 Jun 2011 23:25:03 -0700 From: Tina Tsou In-reply-to: To: 'Fred Baker' , 'Stephen Farrell' Message-id: <020601cc2349$530f5400$f92dfc00$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwjR4ZQpJGdiSiJTVadap3krXe/CwAAbBaw References: <4DEA6323.4070302@cs.tcd.ie> Cc: "'Turner, Sean P.'" , ipv6@ietf.org, v6ops@ietf.org, 'Eliot Lear' , saag@ietf.org Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 06:25:16 -0000 Hi, RFC 4775 is the process to follow. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Fred Baker Sent: Saturday, June 04, 2011 11:10 PM To: Stephen Farrell Cc: Turner, Sean P.; v6ops@ietf.org; ipv6@ietf.org; saag@ietf.org; Eliot Lear Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison On Jun 4, 2011, at 9:53 AM, Stephen Farrell wrote: > I think we'd like to respond to them that that's great, > and we'll be interested in their results, but can they > *please* come back to us before saying something should > be changed so's we can talk about it. That seems like a reasonable proposal. There a, of course, several proposed sets of security guidelines for IPv6 floating in the breeze. If you want my druthers, I would like to see a comprehensive security *architecture*. Steve Kent wrote to me last month, on another topic, saying > I do have a few comments about the discuss of secruity, in general. I see that you used the CIA model for describing security requirements/services. Although this is a commonly used model, I find it inferior to the model that was developed by ISO in the mid 80's (ISO 7498-2). It might be worthwhile to look at the ISO model he suggests as a possible starting point. To my mind, anything resembling a security architecture will identify threats at the physical, link, network (LAN and IP), transport, and applications layers, and make recommendations for addressing them - and not start from the premise of a global federated identity, which doesn't exist. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From fred@cisco.com Sat Jun 4 23:33:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8955711E808C; Sat, 4 Jun 2011 23:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyAWNNSOAZEj; Sat, 4 Jun 2011 23:33:40 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6CA11E8072; Sat, 4 Jun 2011 23:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1585; q=dns/txt; s=iport; t=1307255620; x=1308465220; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=gBI06pG8hja0PoRnlP78Ei2x232f8DDCsM2JN7aXahQ=; b=gLEckFLJxIGOLx3ipwVvBPhVAXX1gxndLw/JV0iOTfMewyopSg0VG7ng ZXFXXeUpnVBqJ6cDwxOy/j0Tf33lnPk1T0878KfjIgUVLTQvPjHy/WEMV i104iuQAFo26xVAL8BMxPoJ/QLjlfYJMx+14SoyuUqnJYEq5iF4RIv8ON g=; X-IronPort-AV: E=Sophos;i="4.65,321,1304294400"; d="scan'208";a="330349821" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 05 Jun 2011 06:33:40 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p556XYgD019240; Sun, 5 Jun 2011 06:33:39 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sat, 04 Jun 2011 23:33:40 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sat, 04 Jun 2011 23:33:40 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sat, 4 Jun 2011 23:33:24 -0700 Message-Id: <1B36FABA-D389-4804-A45B-8F49BD7D8ECB@cisco.com> References: <4DEA6323.4070302@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "Turner, Sean P." , 6man Mailing List , IPv6 Operations Working Group , Eliot Lear , saag@ietf.org Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 06:33:41 -0000 BTW, in case it wasn't clear, I think the IETF should do that = architecture. On Jun 4, 2011, at 11:10 PM, Fred Baker wrote: >=20 > On Jun 4, 2011, at 9:53 AM, Stephen Farrell wrote: >=20 >> I think we'd like to respond to them that that's great, >> and we'll be interested in their results, but can they >> *please* come back to us before saying something should >> be changed so's we can talk about it. >=20 > That seems like a reasonable proposal.=20 >=20 > There a, of course, several proposed sets of security guidelines for = IPv6 floating in the breeze. If you want my druthers, I would like to = see a comprehensive security *architecture*. Steve Kent wrote to me last = month, on another topic, saying >=20 >> I do have a few comments about the discuss of secruity, in general. I = see that you used the CIA model for describing security = requirements/services. Although this is a commonly used model, I find it = inferior to the model that was developed by ISO in the mid 80's (ISO = 7498-2). >=20 > It might be worthwhile to look at the ISO model he suggests as a = possible starting point.=20 >=20 > To my mind, anything resembling a security architecture will identify = threats at the physical, link, network (LAN and IP), transport, and = applications layers, and make recommendations for addressing them - and = not start from the premise of a global federated identity, which doesn't = exist. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From arturo.servin@gmail.com Sun Jun 5 13:31:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A34221F84BC; Sun, 5 Jun 2011 13:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gmi-9yfQfRU; Sun, 5 Jun 2011 13:31:03 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCBC521F84BB; Sun, 5 Jun 2011 13:30:59 -0700 (PDT) Received: by wyb29 with SMTP id 29so2873179wyb.31 for ; Sun, 05 Jun 2011 13:30:59 -0700 (PDT) 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=JhPE23+t/7g7fRBD7ic0InIjd0Ip/qZ8bHxVe6CqBUA=; b=mo+YtVdGIqwjxyPWBBTOSSxIfWbPu6A86dNtxTqyKECRu+MtSJBIMYoXVRH8EmIOBW vvhZ755aO489tA/rKl4RrQl2yD6s9yhOxOSVRxY+DEpwlCiMpypoiloTy9mgu+cD8ihJ 4jlAwMezf+ernZj4WBiXhl4tODfmIokZmE7Ks= 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=Qg/zxP9mxtVjNY0tzA192wyWjN5C9iy1rXZKdnlbVX/w6fyjjiv85uOS8wwuS3S+vn j1NNbnVSsti8E/DpczqSWfVbeEIFYe5wIwD6Hn8Xj/hI68eG/cYRYAqPHQpAdREirBE9 cc6MoxNgrtUMkZopx++H2PSIXP6dgfftHlKAE= Received: by 10.227.57.148 with SMTP id c20mr4231397wbh.54.1307305858776; Sun, 05 Jun 2011 13:30:58 -0700 (PDT) Received: from [10.225.103.220] ([83.111.212.208]) by mx.google.com with ESMTPS id o38sm2424267wba.3.2011.06.05.13.30.56 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Jun 2011 13:30:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <20110605031045.GK88250@verdi> Date: Sun, 5 Jun 2011 17:30:54 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DEA6323.4070302@cs.tcd.ie> <20110605031045.GK88250@verdi> To: IPv6 Operations , ipv6@ietf.org X-Mailer: Apple Mail (2.1084) Cc: "Turner, Sean P." , John Leslie , saag@ietf.org, Eliot Lear , Stephen Farrell Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 20:31:04 -0000 I do not see why the ITU has to start from zero. There are = several (or some at least) very good RFC and I+D documents related to = IPv6 security. I think we should recommend them to ITU, it is good that = they let us know, it would be better if they use our work as a = foundation. just my 20 cents -as On 5 Jun 2011, at 00:10, John Leslie wrote: > Stephen Farrell wrote: >>=20 >> We received a liaison [1] from ITU-T saying they're >> planning to start a couple of work items on the >> security of IPv6. As far as we know, they envisage >> developing a "technical guideline on deploying IPv6" >> and "Security Management Guideline for implementation >> of IPv6 environment in telecommunications >> organizations." Bear in mind that they're just starting >> so they know about as much as we would just before a >> BoF or something like that. >>=20 >> I think we'd like to respond to them that that's great, >> and we'll be interested in their results, but can they >> *please* come back to us before saying something should >> be changed so's we can talk about it. >=20 > I don't think that's quite right. We should welcome their studying > security issues; but I think we need to _strongly_ encourage them to > start from draft-ietf-6man-node-req-bis when it becomes an RFC -- = since > it has _significant_ changes from RFC 4294 (and an ITU-T study based > on RFC4294 will be of rather limited value). >=20 > Furthermore, ITU-T should NOT propose "changes" to IPv6 protocol > or the Node Requirements. The language there should talk of = documenting > security "concerns" or "issues" or whatever term seems neutral enough; > and list as the next step exchanging ideas of what "changes" might = help. >=20 > Clearly, ITU-T is entirely justified in publishing recommendations > of what level of security-related-trust to place in IPv6 packet > forwarding: but any protocol _changes_ are outside their bailiwick. >=20 > (As an aside, IETF should resist most proposals for change until > IPv6 sees widespread deployment -- deploying to a moving target is > just TOO risky.) >=20 > -- > John Leslie > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From internet-drafts@ietf.org Mon Jun 6 00:58:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAD411E8099; Mon, 6 Jun 2011 00:58:46 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkafT2xixjaO; Mon, 6 Jun 2011 00:58:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AA21F0C4B; Mon, 6 Jun 2011 00:58:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110606075845.27443.7480.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2011 00:58:45 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 07:58:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Request to move Connection of IPv6 Domains via IPv4 Clou= ds (6to4) to Historic status Author(s) : Ole Troan Filename : draft-ietf-v6ops-6to4-to-historic-04.txt Pages : 7 Date : 2011-06-06 Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6 transitioning mechanism has shown that the mechanism is unsuitable for widespread deployment and use in the Internet. This document requests that RFC3056 and the companion document "An Anyca= st Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-to-historic-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-to-historic-04.txt From lear@cisco.com Mon Jun 6 03:06:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2A911E80F0; Mon, 6 Jun 2011 03:06:38 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQUBFjuXwGao; Mon, 6 Jun 2011 03:06:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 54F0711E808C; Mon, 6 Jun 2011 03:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=7439; q=dns/txt; s=iport; t=1307354797; x=1308564397; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=1uYQGLju7XRr6KKlj3vz0+0SQKDvRvj2ZAbOgZXNl/s=; b=GahtMpq8ogb0webfuD430Y2xoxLU/tlN5idcn4rBommQvea4m5s4Fnkw 70GfGyb3RIcYM1SRs/SJgqzLv7tb38a+9s+OMuga/O0qaNYdYgXFCh21H HDTmwv17WklLiSdrGN3StGg53spGmknl9efnmHMKDLUPKnirG9zy91x3X w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALul7E1Io8UQ/2dsb2JhbABThEqhcHetV40JkBmFF4EKBJB5jzw X-IronPort-AV: E=Sophos;i="4.65,325,1304294400"; d="scan'208,217";a="92408112" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 06 Jun 2011 10:06:05 +0000 Received: from dhcp-10-55-89-175.cisco.com (dhcp-10-55-89-175.cisco.com [10.55.89.175]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p56A62MF020755; Mon, 6 Jun 2011 10:06:02 GMT Message-ID: <4DECA68A.6080305@cisco.com> Date: Mon, 06 Jun 2011 12:06:02 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Arturo Servin References: <4DEA6323.4070302@cs.tcd.ie> <20110605031045.GK88250@verdi> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------070307020309060605080903" X-Mailman-Approved-At: Mon, 06 Jun 2011 03:10:35 -0700 Cc: IPv6 Operations , ipv6@ietf.org, saag@ietf.org, "Turner, Sean P." , John Leslie , Stephen Farrell Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 10:06:38 -0000 This is a multi-part message in MIME format. --------------070307020309060605080903 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Arturo, On 6/5/11 10:30 PM, Arturo Servin wrote: > I do not see why the ITU has to start from zero. There are several (or some at least) very good RFC and I+D documents related to IPv6 security. I think we should recommend them to ITU, it is good that they let us know, it would be better if they use our work as a foundation. There are several specific areas of interest that you can view at https://datatracker.ietf.org/documents/LIAISON/file1228.pdf. The chairman and vice-chairman of the ITU's security area, SG17, are informing us that two of their working groups which the ITU-T calls Questions will be taking on new work relating to IPv6. Let's review the two work items: The first thing to note is that X.ipv6-secguide is targeted to be a deployment guide. We need more of these for IPv6 and we should welcome the ITU-T's involvement. The second document, X.mgv6 is meant to be "management guidelines for implementation of IPv6". We provide a fair amount of this sort of guidance in our collective works. Also, the difference between implementation guidance and normative statements can be very narrow. Therefore, this is the area most likely to have overlap. The best way to address that overlap is to communicate effectively through the liaison process, and perhaps to also participate directly in the meetings, when possible. Here the chairman and vice-chairman of SG17 have recognized that the IETF is an important player in the work to be done. While no response has been requested, it would be wise for us to provide the relevant related work so, as you say, the ITU-T doesn't attempt to start from scratch. I hasten to point out that they are by no means starting from scratch, but we should still provide them relevant guidance. So what is relevant guidance? That can take several different forms: 1. Direct participation in the Study Group meetings. Study Group meetings are open to Member States and Sector Members. ISOC is a Sector Member. The IETF on its own is not. 2. Concise and relevant liaison statements. As this work is just beginning, we can point to not only the published RFCs that are relevant, and they include not only RFC 4294 and draft-ietf-6man-node-req-bis (and we can reference this as a work in progress, and in fact invite comment), but also relevant portions of other RFCs, particular their relevant Security Considerations sections. 3. Informal consultations with ITU-T participants. Believe it or not, this is often the most effective way to contribute. At the same time we should invite SG17 to provide us any feedback on our works, especially when they discover any of the following: * A security problem; * An obstacle to deployment; or * An interoperability problem. While this solicitation should not be limited to the ITU-T, that organization has a reach into the developing world that quite frankly we do not, and they may spot issues that relate to certain environments. Hope this helps, Eliot --------------070307020309060605080903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Arturo,

On 6/5/11 10:30 PM, Arturo Servin wrote: 
	I do not see why the ITU has to start from zero. There are several (or some at least) very good RFC and I+D documents related to IPv6 security. I think we should recommend them to ITU, it is good that they let us know, it would be better if  they use our work as a foundation.


There are several specific areas of interest that you can view at https://datatracker.ietf.org/documents/LIAISON/file1228.pdf.  The chairman and vice-chairman of the ITU's security area, SG17, are informing us that two of their working groups which the ITU-T calls Questions will be taking on new work relating to IPv6.

Let's review the two work items:

The first thing to note is that X.ipv6-secguide is targeted to be a deployment guide.  We need more of these for IPv6 and we should welcome the ITU-T's involvement.

The second document, X.mgv6 is meant to be "management guidelines for implementation of IPv6".   We provide a fair amount of this sort of guidance in our collective works.  Also, the difference between implementation guidance and normative statements can be very narrow.  Therefore, this is the area most likely to have overlap.  The best way to address that overlap is to communicate effectively through the liaison process, and perhaps to also participate directly in the meetings, when possible.

Here the chairman and vice-chairman of SG17 have recognized that the IETF is an important player in the work to be done.  While no response has been requested, it would be wise for us to provide the relevant related work so, as you say, the ITU-T doesn't attempt to start from scratch.  I hasten to point out that they are by no means starting from scratch, but we should still provide them relevant guidance.  So what is relevant guidance?  That can take several different forms:

  1. Direct participation in the Study Group meetings.  Study Group meetings are open to Member States and Sector Members.  ISOC is a Sector Member.  The IETF on its own is not.
  2. Concise and relevant liaison statements.  As this work is just beginning, we can point to not only the published RFCs that are relevant, and they include not only RFC 4294 and draft-ietf-6man-node-req-bis (and we can reference this as a work in progress, and in fact invite comment), but also relevant portions of other RFCs, particular their relevant Security Considerations sections.
  3. Informal consultations with ITU-T participants.  Believe it or not, this is often the most effective way to contribute.
At the same time we should invite SG17 to provide us any feedback on our works, especially when they discover any of the following:
  • A security problem;
  • An obstacle to deployment; or
  • An interoperability problem.
While this solicitation should not be limited to the ITU-T, that organization has a reach into the developing world that quite frankly we do not, and they may spot issues that relate to certain environments.

Hope this helps,

Eliot
--------------070307020309060605080903-- From pekkas@netcore.fi Mon Jun 6 03:43:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8053011E80F4 for ; Mon, 6 Jun 2011 03:43:45 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It5dRTiBMD7Q for ; Mon, 6 Jun 2011 03:43:45 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8515A11E80DA for ; Mon, 6 Jun 2011 03:43:44 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p56AhGI4010064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jun 2011 13:43:17 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p56AhCKR010061; Mon, 6 Jun 2011 13:43:12 +0300 Date: Mon, 6 Jun 2011 13:43:12 +0300 (EEST) From: Pekka Savola To: Thomas Narten In-Reply-To: <201106021939.p52Jd8rI002414@cichlid.raleigh.ibm.com> Message-ID: References: <4DE6DD93.507@gont.com.ar> <4DE7D813.3050700@gont.com.ar> <201106021939.p52Jd8rI002414@cichlid.raleigh.ibm.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi X-Virus-Status: Clean Cc: IPv6 Operations Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 10:43:45 -0000 On Thu, 2 Jun 2011, Thomas Narten wrote: >>> What if the list of More Specific Route options is large enough that they won't all fit in a single Router Advertisement message? > >> You send them in separate RAs. > > Right. You fragment at the transport layer. > > That said, I am not at all convinced that we should outlaw the use of > fragmentation for ND. > > RA-Guard is not a perfect solution to RA spoofing. It never will > be. It has limitations (and always will). ND packets that using > extension headers or fragmentation are just one specific example. This has happened with radvd. There was one individual who very strongly insisted (by filing and bugging about that in a bug report at Red Hat Bugzilla) that he must be able to advertise his whole /48, i.e., 64K prefix information options. That resulted in the implementation fragmenting packets at the IP layer. Transport layer would fragmentation to multiple RAs would have been possible as well but there was no point in implementing that. I solved the "problem" by restricting radvd send buffer size to 1452B, so both are prevented. I wouldn't be sad to see the RA transport/IP layer fragmentation go. -- 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 stephen.farrell@cs.tcd.ie Mon Jun 6 04:41:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DA211E80F8; Mon, 6 Jun 2011 04:41:41 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcGkv6PgkxUu; Mon, 6 Jun 2011 04:41:40 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2D04211E80D6; Mon, 6 Jun 2011 04:41:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5A76C171C18; Mon, 6 Jun 2011 12:41:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1307360497; bh=HGQZCafMYnnf4+ cQeY11uzwY5tWANiICFL/8uDkNxpc=; b=uuju7tFoXlq6V7j4TQGbUxhLmSXQ/P EzPwhIvHKGeDqINtSypNv6oimK3d1264ZRpmnMZgK6mu/toqCVoYeo5o4jBlxIeG DZ4Mmul6h47NwGgIwUUQw2PKwvJO91Qt1H+K0hpviG1crqV5iWiP1qNFALBqagHQ s8EZmA5IVcYa6pTsmj6VO9h4LoGxTLG0m7avfJ3+inkTDfUoGWZa1iWijSLBqwse WjLWBORn/Q59GfcpiXn6TtsKkX1CmzGfnN2JmS5gZxKVa1X4FxUvbjcO3H63Jcaw LbosmpcuFhP2F+AMMwgM2UhGpFoU6zxkl1ToBOjXBNgrrldZfhl5O+QA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id o8oaWcScZvBj; Mon, 6 Jun 2011 12:41:37 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.182.86]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2C0D8171C17; Mon, 6 Jun 2011 12:41:35 +0100 (IST) Message-ID: <4DECBCEE.6070108@cs.tcd.ie> Date: Mon, 06 Jun 2011 12:41:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Arturo Servin References: <4DEA6323.4070302@cs.tcd.ie> <20110605031045.GK88250@verdi> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , ipv6@ietf.org, Eliot Lear , saag@ietf.org, "Turner, Sean P." , John Leslie Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 11:41:41 -0000 On 05/06/11 21:30, Arturo Servin wrote: > > I do not see why the ITU has to start from zero. What Eliot said. > There are several (or some at least) very good RFC and I+D documents related to IPv6 security. Sure. Feel free to send RFC numbers and we'll include some in the draft response that we'll circulate in a while. (So no need to spam everyone with those, just sending your suggestions to Eliot, Sean and I will be enough.) Thanks, S. > I think we should recommend them to ITU, it is good that they let us know, it would be better if they use our work as a foundation. > > just my 20 cents > -as > > > On 5 Jun 2011, at 00:10, John Leslie wrote: > >> Stephen Farrell wrote: >>> >>> We received a liaison [1] from ITU-T saying they're >>> planning to start a couple of work items on the >>> security of IPv6. As far as we know, they envisage >>> developing a "technical guideline on deploying IPv6" >>> and "Security Management Guideline for implementation >>> of IPv6 environment in telecommunications >>> organizations." Bear in mind that they're just starting >>> so they know about as much as we would just before a >>> BoF or something like that. >>> >>> I think we'd like to respond to them that that's great, >>> and we'll be interested in their results, but can they >>> *please* come back to us before saying something should >>> be changed so's we can talk about it. >> >> I don't think that's quite right. We should welcome their studying >> security issues; but I think we need to _strongly_ encourage them to >> start from draft-ietf-6man-node-req-bis when it becomes an RFC -- since >> it has _significant_ changes from RFC 4294 (and an ITU-T study based >> on RFC4294 will be of rather limited value). >> >> Furthermore, ITU-T should NOT propose "changes" to IPv6 protocol >> or the Node Requirements. The language there should talk of documenting >> security "concerns" or "issues" or whatever term seems neutral enough; >> and list as the next step exchanging ideas of what "changes" might help. >> >> Clearly, ITU-T is entirely justified in publishing recommendations >> of what level of security-related-trust to place in IPv6 packet >> forwarding: but any protocol _changes_ are outside their bailiwick. >> >> (As an aside, IETF should resist most proposals for change until >> IPv6 sees widespread deployment -- deploying to a moving target is >> just TOO risky.) >> >> -- >> John Leslie >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From Marcus.Williams@ed.gov Mon Jun 6 05:58:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D517E11E8133; Mon, 6 Jun 2011 05:58:59 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhOUReTY2FiE; Mon, 6 Jun 2011 05:58:58 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by ietfa.amsl.com (Postfix) with ESMTP id C5F7211E813A; Mon, 6 Jun 2011 05:58:50 -0700 (PDT) Received: from eduptcexmr01.ed.gov ([160.109.63.134]) (using TLSv1) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKTezPCDt5UDjv8KpyC7/7hKf9QEZqoPtb@postini.com; Mon, 06 Jun 2011 05:58:58 PDT Received: from eduptcexhb02.ed.gov (eduptcexhb02.ed.gov [165.224.52.34]) by eduptcexmr01.ed.gov (8.13.8/8.13.8) with ESMTP id p56CwkdX002512 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 6 Jun 2011 07:58:46 -0500 Received: from EDUPTCEXMB02.ed.gov ([165.224.52.20]) by eduptcexhb02.ed.gov ([165.224.52.34]) with mapi; Mon, 6 Jun 2011 07:58:46 -0500 From: "Williams, Marcus (Contractor)" To: Stephen Farrell , Arturo Servin Date: Mon, 6 Jun 2011 07:58:43 -0500 Thread-Topic: [v6ops] ITU-T SG17 IPv6 security work items liaison Thread-Index: AcwkPt1LDZw3bbl2TWqChG/iXIKbYgACZ7YA Message-ID: References: <4DEA6323.4070302@cs.tcd.ie> <20110605031045.GK88250@verdi> <4DECBCEE.6070108@cs.tcd.ie> In-Reply-To: <4DECBCEE.6070108@cs.tcd.ie> 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: IPv6 Operations , "ipv6@ietf.org" , Eliot Lear , "saag@ietf.org" , "Turner, Sean P." , John Leslie Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 12:58:59 -0000 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Stephen Farrell > Sent: Monday, June 06, 2011 7:42 AM > Sure. Feel free to send RFC numbers and we'll include > some in the draft response that we'll circulate in a > while. (So no need to spam everyone with those, just > sending your suggestions to Eliot, Sean and I will be > enough.) There are a number of RFCs including 4291 already referenced in this NIST S= pecial Publication 800-119, Guidelines for the Secure Deployment of IPv6: http://csrc.nist.gov/publications/PubsDrafts.html#800-119 Marcus Williams, CISSP From iesg-secretary@ietf.org Mon Jun 6 09:23:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C282711E8172; Mon, 6 Jun 2011 09:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+vrB-zBtgHl; Mon, 6 Jun 2011 09:23:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BB111E8137; Mon, 6 Jun 2011 09:23:26 -0700 (PDT) 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.55 Message-ID: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2011 09:23:26 -0700 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 16:23:29 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6 transitioning mechanism has shown that the mechanism is unsuitable for widespread deployment and use in the Internet. This document requests that RFC3056 and the companion document "An Anycast Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ No IPR declarations have been submitted directly on this I-D. From moore@network-heretics.com Mon Jun 6 10:22:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8456F11E819F; Mon, 6 Jun 2011 10:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzvtSnDlIN+j; Mon, 6 Jun 2011 10:22:31 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2A18B11E8194; Mon, 6 Jun 2011 10:22:31 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 698E420C50; Mon, 6 Jun 2011 13:22:30 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute6.internal (MEProxy); Mon, 06 Jun 2011 13:22:30 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=ZFmALFB4p9jXUV17JlbFTbzclrc=; b=jsm9+KWO8zTnAOemjqWwiBAJjY7aEc6kujqGf4WjMul1ySfTBH9maVXHh9t98hfnKafexm7Wp+W7WN5AldwaA2vtKiUZMyd2AjLKTu2K0nTIt0YAN8r1CGO6v1Vw4WypJtoYvgmB8uVB8Nw2AL4RvbO3cAXKapCbZrp1QsISLiE= X-Sasl-enc: qHLxH8LQL2luuSbwtLtjkKc57dcZ+ieQttjccTSICfag 1307380948 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 5F440441792; Mon, 6 Jun 2011 13:22:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-508749156 From: Keith Moore In-Reply-To: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> Date: Mon, 6 Jun 2011 13:22:27 -0400 Message-Id: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, IETF-Announce Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 17:22:32 -0000 --Apple-Mail-2-508749156 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I strongly object to the proposed reclassification of these documents as = Historic. =20 6to4 still has many valid use cases, and there is not a suitable = replacement for it that has been deployed. Until there is a suitable = replacement, or until there is widespread ISP support for native IPv6, = reclassification of this document to Historic is premature. (6rd is not = a suitable replacement for 6to4, as it is intended for very different = use cases than 6to4.) (It could be argued that reclassification of RFC 3068 (by itself) to = Historic is appropriate, but that would require a separate document and = last call.) In addition, this document is misleading and perhaps even vituperative. = For instance: "There would appear to be no evidence of any substantial deployment of = the variant of 6to4 described in [RFC3056]." This statement is blatantly false. 6to4 is supported by every major = desktop and server platfrom that is shipping today, and has been = supported for several years. "The IETF sees no evolutionary future for the mechanism and it is not = recommended to include this mechanism in new implementations." 6to4 never was intended to have an "evolutionary future". It was always = intended as a near-term solution to allow consenting hosts and networks = to interchange IPv6 traffic without prior support from the IPv4 networks = that carry the traffic. It is premature to recommend that 6to4 be = removed from implementations. We do not know how long it will take ISPs = to universally deploy IPv6. Until they do, there will be a need for = individuals and enterprises using IPv6-based applications to be able to = exchange IPv6 traffic with hosts that only have IPv4 connectivity. =20 All of the criticisms in section 3 have to do with the use of relays to = exchange traffic between 6to4 and native IPv6. In many cases the = criticisms are overbroad. Not all uses of 6to4 involve relays. For = some of those that do need to use relays, it is not necessarily the case = that the relay is operated by an unknown third-party. =20 The fact that some firewalls block protocol 41 traffic causes problems = for many tunneling solutions, not just 6to4; yet this document appears = to recommend some tunneling solutions while trashing 6to4. The recommendations to treat 6to4 as a service of last resort will do = harm to users and applications using it. A better recommendation is = for hosts to disable 6to4 by default. =20 This document appears to make the mistake of assuming that the purpose = of applications using IPv6 is to interoperate with the existing = Internet. I have maintained for many years that it is new applications, = or existing applications that can't tolerate widespread deployment of = IPv4 NAT, that will drive use of IPv6. I therefore believe that it is = inappropriate to judge 6to4 merely by how well it works in scenarios = where it is being used to talk to applications that work well over IPv4 = NAT such as HTTP. The Internet is much more diverse than that, and = will become even more diverse as IPv6 enjoys wider deployment. It is also premature to remove references to 6to4 from RFC 5156bis, for = IANA to mark the prefix and DNS zones as deprecated. This will only = cause confusion and difficulty for legitimate continued uses of 6to4. Keith On Jun 6, 2011, at 12:23 PM, The IESG wrote: >=20 > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) = to > Historic status' > as an Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-06-20. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > Experience with the "Connection of IPv6 Domains via IPv4 Clouds > (6to4)" IPv6 transitioning mechanism has shown that the mechanism is > unsuitable for widespread deployment and use in the Internet. This > document requests that RFC3056 and the companion document "An = Anycast > Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-2-508749156 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = strongly object to the proposed reclassification of these documents as = Historic.  

6to4 still has many valid use cases, = and there is not a suitable replacement for it that has been deployed. =  Until there is a suitable replacement, or until there is = widespread ISP support for native IPv6, reclassification of this = document to Historic is premature.  (6rd is not a suitable = replacement for 6to4, as it is intended for very different use cases = than 6to4.)

(It could be argued that = reclassification of RFC 3068 (by itself) to Historic is appropriate, but = that would require a separate document and last = call.)

In addition, this document is misleading and = perhaps even vituperative.    For = instance:

"There would =
appear to be no evidence of any substantial deployment of the variant of =
6to4 described in [RFC3056]."

This statement is blatantly false. 6to4 is =
supported by every major desktop and server platfrom that is shipping =
today, and has been supported for several =
years.

"The IETF sees no evolutionary future for the mechanism and it is =
not recommended to include this mechanism in new =
implementations."

6to4= never was intended to have an "evolutionary future".  It was = always intended as a near-term solution to allow consenting hosts and = networks to interchange IPv6 traffic without prior support from the IPv4 = networks that carry the traffic.   It is premature to recommend = that 6to4 be removed from implementations.  We do not know how long = it will take ISPs to universally deploy IPv6.  Until they do, there = will be a need for individuals and enterprises using IPv6-based = applications to be able to exchange IPv6 traffic with hosts that only = have IPv4 connectivity.  

All of the = criticisms in section 3 have to do with the use of relays to exchange = traffic between 6to4 and native IPv6.   In many cases the = criticisms are overbroad.   Not all uses of 6to4 involve relays. =  For some of those that do need to use relays, it is not = necessarily the case that the relay is operated by an unknown = third-party.  

The fact that some = firewalls block protocol 41 traffic causes problems for many tunneling = solutions, not just 6to4; yet this document appears to recommend some = tunneling solutions while trashing 6to4.

The = recommendations to treat 6to4 as a service of last resort will do harm = to users and applications using it.   A better recommendation is = for hosts to disable 6to4 by default. =  

This document appears to make the = mistake of assuming that the purpose of applications using IPv6 is to = interoperate with the existing Internet.  I have maintained for = many years that it is new applications, or existing applications that = can't tolerate widespread deployment of IPv4 NAT, that will drive use of = IPv6.   I therefore believe that it is inappropriate to judge 6to4 = merely by how well it works in scenarios where it is being used to talk = to applications that work well over IPv4 NAT such as HTTP.   The = Internet is much more diverse than that, and will become even more = diverse as IPv6 enjoys wider deployment.

It is = also premature to remove references to 6to4 from RFC 5156bis, for IANA = to mark the prefix and DNS zones as deprecated.  This will only = cause confusion and difficulty for legitimate continued uses of = 6to4.

Keith


On Jun 6, 2011, at 12:23 PM, The IESG wrote:


The= IESG has received a request from the IPv6 Operations WG (v6ops) = to
consider the following document:
- 'Request to move Connection = of IPv6 Domains via IPv4 Clouds (6to4) to
  Historic = status'
 <draft-ietf-v6ops-6to4-to-historic-04.txt> as an = Informational RFC

The IESG plans to make a decision in the next = few weeks, and solicits
final comments on this action. Please send = substantive comments to the
ietf@ietf.org mailing lists by = 2011-06-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, = please retain the
beginning of the Subject line to allow automated = sorting.

Abstract


  Experience with the = "Connection of IPv6 Domains via IPv4 Clouds
  (6to4)" IPv6 = transitioning mechanism has shown that the mechanism is
=   unsuitable for widespread deployment and use in the = Internet.  This
  document requests that RFC3056 and = the companion document "An Anycast
  Prefix for 6to4 Relay = Routers" RFC3068 are moved to historic status.




The = file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/
IESG discussion can be tracked = via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/<= br>

No IPR declarations have been submitted directly on this = I-D.


_______________________________________________
IETF-An= nounce mailing = list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ie= tf-announce

= = --Apple-Mail-2-508749156-- From wesley.george@twcable.com Mon Jun 6 10:35:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68F811E8090 for ; Mon, 6 Jun 2011 10:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJq8f5V56HtT for ; Mon, 6 Jun 2011 10:35:44 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id DEC0511E8085 for ; Mon, 6 Jun 2011 10:35:43 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,327,1304308800"; d="scan'208";a="234611701" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 06 Jun 2011 13:42:32 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Mon, 6 Jun 2011 13:35:43 -0400 From: "George, Wesley" To: "v6ops@ietf.org" Date: Mon, 6 Jun 2011 13:35:42 -0400 Thread-Topic: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC Thread-Index: AcwkZhpBkLv0cIo/TqGK4CFl8qO7ugACa7jg Message-ID: <34E4F50CAFA10349A41E0756550084FB067B6FD5@PRVPEXVS04.corp.twcable.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> In-Reply-To: <20110606162326.26262.53944.idtracker@ietfa.amsl.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 Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 17:35:44 -0000 Did I miss the discussion where we decided to make this informational inste= ad of proposed standard? What was the rationale? Thanks, Wes George -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of T= he IESG Sent: Monday, June 06, 2011 12:23 PM To: IETF-Announce Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Req= uest to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic = status) to Informational RFC The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6 transitioning mechanism has shown that the mechanism is unsuitable for widespread deployment and use in the Internet. This document requests that RFC3056 and the companion document "An Anycast Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From rbonica@juniper.net Mon Jun 6 11:50:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DF111E81B8 for ; Mon, 6 Jun 2011 11:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAY3u4q1O1dT for ; Mon, 6 Jun 2011 11:50:37 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 01C8011E816B for ; Mon, 6 Jun 2011 11:50:28 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTe0hcaAlizhaT8WNz/Nd9WPCSi9Jdle7@postini.com; Mon, 06 Jun 2011 11:50:37 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 6 Jun 2011 11:49:28 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 6 Jun 2011 14:49:19 -0400 From: Ronald Bonica To: "George, Wesley" , "v6ops@ietf.org" Date: Mon, 6 Jun 2011 14:49:18 -0400 Thread-Topic: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC Thread-Index: AcwkZhpBkLv0cIo/TqGK4CFl8qO7ugACa7jgAAKG5iA= Message-ID: <13205C286662DE4387D9AF3AC30EF456D3A20C4858@EMBX01-WF.jnpr.net> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B6FD5@PRVPEXVS04.corp.twcable.com> In-Reply-To: <34E4F50CAFA10349A41E0756550084FB067B6FD5@PRVPEXVS04.corp.twcable.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 Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 18:50:38 -0000 Hi Wes, The reason was that it could achieve its goal as INFORMATIONAL. Specificall= y, the mechanism for obsoleting a document and changing its status to HISTO= RIC is to write another RFC. However, that new RFC does need to have the sa= me status as the document that it obsoletes. An INFORMATIONAL RFC is suffic= ient to obsolete a PS RFC. Ron =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of G= eorge, Wesley Sent: Monday, June 06, 2011 1:36 PM To: v6ops@ietf.org Subject: Re: [v6ops] Last Call: = (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Histo= ric status) to Informational RFC Did I miss the discussion where we decided to make this informational inste= ad of proposed standard? What was the rationale? Thanks, Wes George -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of T= he IESG Sent: Monday, June 06, 2011 12:23 PM To: IETF-Announce Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Req= uest to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic = status) to Informational RFC The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6 transitioning mechanism has shown that the mechanism is unsuitable for widespread deployment and use in the Internet. This document requests that RFC3056 and the companion document "An Anycast Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Mon Jun 6 11:52:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D5B11E816B for ; Mon, 6 Jun 2011 11:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.099 X-Spam-Level: X-Spam-Status: No, score=-110.099 tagged_above=-999 required=5 tests=[AWL=-0.100, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7BijiZVBzGL for ; Mon, 6 Jun 2011 11:52:09 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 346BA11E816A for ; Mon, 6 Jun 2011 11:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3212; q=dns/txt; s=iport; t=1307386329; x=1308595929; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=bgaHlTcluEP3bv6R+vjjcE2Ud/XWh/1y4xEq8s4Axg8=; b=Oo+Mcz/cAamkKMd7cG2Bw/yGsRvMToo007s7srkgE6tTqWWVGua1QXlR qmWiAjTlpKnj6V4Bd5O0VjZkUjrrEvGhUi12mGJoabT4d1Oz1c2LpWds/ SilmcPd0X1UGdL9Q1hE3zY83cmgTw2g8NgoZ8Rg+/LWXwXwLMPpPpbMnq s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBAPkg7U2rRDoJ/2dsb2JhbABTl0SOYneIcaJtnXyGIQSGdIoFhEiLEg X-IronPort-AV: E=Sophos;i="4.65,327,1304294400"; d="scan'208";a="709004910" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 06 Jun 2011 18:52:08 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p56Iq3P1025566; Mon, 6 Jun 2011 18:52:08 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 06 Jun 2011 11:52:08 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 06 Jun 2011 11:52:08 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <34E4F50CAFA10349A41E0756550084FB067B6FD5@PRVPEXVS04.corp.twcable.com> Date: Mon, 6 Jun 2011 11:51:52 -0700 Message-Id: <1EF6364A-8B57-498E-B32C-2B588591CFB0@cisco.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B6FD5@PRVPEXVS04.corp.twcable.com> To: "George, Wesley" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 18:52:10 -0000 On Jun 6, 2011, at 10:35 AM, George, Wesley wrote: > Did I miss the discussion where we decided to make this informational = instead of proposed standard? What was the rationale? Requested by the AD. The argument for standards track was that it = addressed a standards track document. The IESG apparently opines that an = informational document will do the job and is their preference. > Thanks, >=20 > Wes George >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of The IESG > Sent: Monday, June 06, 2011 12:23 PM > To: IETF-Announce > Cc: v6ops@ietf.org > Subject: [v6ops] Last Call: = (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to = Historic status) to Informational RFC >=20 >=20 > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) = to > Historic status' > as an Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-06-20. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > Experience with the "Connection of IPv6 Domains via IPv4 Clouds > (6to4)" IPv6 transitioning mechanism has shown that the mechanism is > unsuitable for widespread deployment and use in the Internet. This > document requests that RFC3056 and the companion document "An = Anycast > Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From behcetsarikaya@yahoo.com Mon Jun 6 14:52:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3FE21F8504 for ; Mon, 6 Jun 2011 14:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bN-R7E7agS4 for ; Mon, 6 Jun 2011 14:52:28 -0700 (PDT) Received: from nm23.bullet.mail.sp2.yahoo.com (nm23.bullet.mail.sp2.yahoo.com [98.139.91.93]) by ietfa.amsl.com (Postfix) with SMTP id 5D6FE21F8500 for ; Mon, 6 Jun 2011 14:52:28 -0700 (PDT) Received: from [98.139.91.62] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 06 Jun 2011 21:52:28 -0000 Received: from [98.139.91.2] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 06 Jun 2011 21:52:28 -0000 Received: from [127.0.0.1] by omp1002.mail.sp2.yahoo.com with NNFMP; 06 Jun 2011 21:52:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 268078.79478.bm@omp1002.mail.sp2.yahoo.com Received: (qmail 18886 invoked by uid 60001); 6 Jun 2011 21:52:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307397147; bh=jrTSkTf15rN67RT095fpc0ZnHF47rCmq3EqMj6ZEbiQ=; 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=kwDtCIp+a1vSBoHLSLbL4Uj28qxX8n3iWgyogVaehNH/Q04K46n0l8A8CorcBclDSfygJAcksvH652SVY074qkyGzwXLsuI7OZ0IChY444sCHQxhLvEnsydxrg+ZrGqrukGjdOFWFud+sb5/ALhEUKaXYd4FsRiPseyKrx3DTBE= 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=cCqcz00LuZwbw7T39KexD9511i+Blp2d9Tp8OZgdvhHT9wneiO7w+hiaM/yGWDrWkjXImAd+PAvHhOwbOQd7PfXnVDcA22N0mNkgTKA7xV/Sliqp7pyrzOgpurs0TLlxCmomEW2TCQlFsjhnU4Tuix/kTk2zUBAtGLISHIJufGA=; Message-ID: <731187.12661.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: Z0mBU6kVM1mPsROoC9lKL5PHZJTvuJixNaLbaTcItH7dSuT 1NFvW1a4kcRl1y7yssnWSJyal0_.699PTdfGOUoDeYsnxHoGDJcLBw8349YX 7RaomfrhQCOhyMuHsoGnRVzcuNB9M9aB0YIZkkHYEuWoDglXVjfLUtTe_rZR M475YgjL9OpRQKCJnfas9EpQRfrj8EslA8Mm3IhhiTxG1beM2yMzuOk7AYDi BcKojGU50yGb2c.hYx8VJ9lqMMCmgWApHxJrwRvjXdXIVH4eKSCTCzujPBhX PfQT4EO1aMpSMmipiWpq7MAcajzicTPwNX.PWPEsCakFf1txLiSOr637Kuo4 kdtkg6w5g_oVmCJJJ6LETU6qcfsm14UoJty5dwUR4uTf1.J_7INjibTty5ZM h7TMc.mHSpBZq.g-- Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Mon, 06 Jun 2011 14:52:27 PDT X-Mailer: YahooMailRC/570 YahooMailWebService/0.8.111.304355 References: <449804.6587.qm@web111416.mail.gq1.yahoo.com> <2960D350-CDE4-4545-8798-48B110EDD601@gmail.com> Date: Mon, 6 Jun 2011 14:52:27 -0700 (PDT) From: Behcet Sarikaya To: Jason Lin In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] New Version Notification for draft-sarikaya-v6ops-prefix-delegation-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2011 21:52:29 -0000 Hi Jason,=0A=0APlease see my replies inline. I think Cameron also has simil= ar concerns, I am =0Areplying to you both.=0A=0A=0A>=0A>I think this draft = is useful for mobile networks. =0A=0AThanks.=0A=0A> But I still have some = =0A>questions and comments:=0A=0ASure.=0A> - What is this draft's final = goal?=0A=0AWe clarified this in Section 1 better now. DHCPv6 PD is a scalab= le method to =0Amanage prefixes, that is the final goal.=0A=0A> - Whethe= r the term 'MN' is the same as 'UE'? If yes, it is better to modify =0A=0A>= the figure 1.=0A=0ADone.=0A=0A> - It is better to provide the full name = of abbreviations. =0ADone.=0A> - In the figure 3, there should be a DHCP= client element in =E2=80=98MN=E2=80=99 and a DHCP =0A=0A>Server element in= AR. Is it better to show them in the figure? =0ADone.=0A> - What are th= e Solicit message and Advertise message shown in figure 3 used =0A=0A>for? = It seems also need to be briefly explained in section 3.2.=0ADone.=0A>=0A= =0ARegards,=0A=0ABehcet=0A From fred@cisco.com Mon Jun 6 18:00:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064B921F84F0 for ; Mon, 6 Jun 2011 18:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.456 X-Spam-Level: X-Spam-Status: No, score=-110.456 tagged_above=-999 required=5 tests=[AWL=-0.457, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlae2bVm0Pu9 for ; Mon, 6 Jun 2011 18:00:18 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6D121F84EF for ; Mon, 6 Jun 2011 18:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=874; q=dns/txt; s=iport; t=1307408418; x=1308618018; h=from:reply-to:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=MnQzDm8VirxOfswjtDIxTB1C3wNiey58NI0PtMapXCY=; b=QLNFEdyfzD+rA7ztcr9wBOKKezsB6jjTc1ei8E3Wz52MXwFuxb1UxKB3 /q9EmEZcRaUE4SFlaX0NzmOzG3KPmjh5sNibI8qrVANvB+z6xZzsHObT2 ktDwIaQsXCCJ198zfb7LcEtKvfyHTwGcB4XizbQVhNptu4O1tRTgTpi2A s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAd37U2rRDoG/2dsb2JhbABTphd3qlmBHZ4VhiEEhnWKDoRMixY X-IronPort-AV: E=Sophos;i="4.65,329,1304294400"; d="scan'208";a="331446135" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2011 01:00:18 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5710Bwi027285 for ; Tue, 7 Jun 2011 01:00:17 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 06 Jun 2011 18:00:17 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 06 Jun 2011 18:00:17 -0700 From: Fred Baker Date: Mon, 6 Jun 2011 18:00:01 -0700 Message-Id: To: "v6ops@ietf.org Working Group" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Call for agenda items X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "v6ops-chairs@tools.ietf.org Chairs" , Ron Bonica List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 01:00:19 -0000 Note that the cut-off date for IETF #81 -00 drafts is 4 July, and for = updates to existing drafts is 11 July. I will obviously need to re-ask this question a month from now, but let = me ask it now. What drafts do you want to discuss, and what talks would = you like to invite in v6ops at IETF #81? That will give folks who need = to update their drafts a little warning. I'll close the poll next = Monday. http://www.surveymonkey.com/s/VSSBKVL One set of talks that I'll simply put on the table is a talk on what = happened (past tense) on June 8, from a service provider perspective, an = enterprise perspective, and a content provider perspective. Especially = with respect to the questions asked in draft-chown-v6ops-call-to-arms, = what happened, what was tested, and what did we learn? If folks have = things to share, please advise the chairs.= From marc.blanchet@viagenie.ca Mon Jun 6 18:09:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFEA11E8070 for ; Mon, 6 Jun 2011 18:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -82 X-Spam-Level: X-Spam-Status: No, score=-82 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ka9bRGnPLuJh for ; Mon, 6 Jun 2011 18:09:41 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id B443921F8477 for ; Mon, 6 Jun 2011 18:09:40 -0700 (PDT) Received: from mbl.local (unknown [IPv6:2607:fa48:6e3e:a070:5ab0:35ff:fe6a:294a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B271421F75 for ; Mon, 6 Jun 2011 21:09:38 -0400 (EDT) Message-ID: <4DED7A3D.1060008@viagenie.ca> Date: Mon, 06 Jun 2011 21:09:17 -0400 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Call for agenda items X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 01:09:42 -0000 Le 11-06-06 21:00, Fred Baker a écrit : > Note that the cut-off date for IETF #81 -00 drafts is 4 July, and for updates to existing drafts is 11 July. > > I will obviously need to re-ask this question a month from now, but let me ask it now. What drafts do you want to discuss, and what talks would you like to invite in v6ops at IETF #81? That will give folks who need to update their drafts a little warning. I'll close the poll next Monday. > > http://www.surveymonkey.com/s/VSSBKVL > > One set of talks that I'll simply put on the table is a talk on what happened (past tense) on June 8, from a service provider perspective, an enterprise perspective, and a content provider perspective. Especially with respect to the questions asked in draft-chown-v6ops-call-to-arms, what happened, what was tested, and what did we learn? If folks have things to share, please advise the chairs. to me, we should reserve significant time for many findings that would follow June 8th. This is the best data points we could have for v6ops charter. Therefore, I would suggest to chair to request as much slot time as possible. My 2 cents, Marc. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- ========= IETF81 Quebec city: http://ietf81.ca IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca Space Assigned Number Authority: http://sanaregistry.org From trejrco@gmail.com Mon Jun 6 16:42:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDFF1F0C4D; Mon, 6 Jun 2011 16:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0UMwWlKgcug; Mon, 6 Jun 2011 16:42:17 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3A61F0C46; Mon, 6 Jun 2011 16:42:09 -0700 (PDT) Received: by yib18 with SMTP id 18so1064791yib.31 for ; Mon, 06 Jun 2011 16:42:09 -0700 (PDT) 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 :from:date:message-id:subject:to:content-type; bh=06DSOfowt/GAcRYT9//rw1jFOWmeUauVvPwM6w3IXA4=; b=pm/O8HrV7l/xfOjv9aypvrrEyCe1NgY8DF2WRldkn+aHOoK4oMMZUt+0jkie7g95yJ X40o9WvjQwtN88Gif4XgyaUj2FOPpBrCbCJMXYMefsX8fAejp0BNbFAEgHX/72DaTtE+ RnZ+VShi/b3EIcEFV/qiCM2kY7fx3OLx/w38E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type; b=L90ruj0Q4f28hJwCNSH+55iTsxt94kHAeOtpUlUTX+DWQY0VrYvYZzslmSrhhgsPKA 2BAeW5PoCGtnIeLqoaYXiM+dkLiN/rH84Pgx7U6jCWpxiwqxmwuht29UmjAFv5mAFJpk 0JkcI83v4iw9p/Ii85qoX1sDP89eNH7CVle84= Received: by 10.91.198.11 with SMTP id a11mr4827959agq.184.1307403729095; Mon, 06 Jun 2011 16:42:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.170.3 with HTTP; Mon, 6 Jun 2011 16:41:49 -0700 (PDT) In-Reply-To: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> From: TJ Date: Mon, 6 Jun 2011 19:41:49 -0400 Message-ID: To: ietf@ietf.org, v6ops@ietf.org, ietf-announce@ietf.org Content-Type: multipart/alternative; boundary=0016367658a3d9cd5104a513a6e8 X-Mailman-Approved-At: Mon, 06 Jun 2011 19:55:40 -0700 Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: trejrco@gmail.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 23:42:18 -0000 --0016367658a3d9cd5104a513a6e8 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 6, 2011 at 13:22, Keith Moore wrote: > I strongly object to the proposed reclassification of these documents as > Historic. > ** > Agreed that this is too harsh, too soon. Fixing the broken implementations is a better idea than trying to break the working ones. And I am not just saying this because I successfully use 6to4 on a fairly common basis ... /TJ --0016367658a3d9cd5104a513a6e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 6, 2011 at 13:22, Keith Moore <moore@net= work-heretics.com> wrote:
I strongly object to the proposed recla= ssification of these documents as Historic. =A0
<snipped lots of = great thoughts/comments, solely for brevity>


Agreed that this is too harsh, too soon. =A0Fixing the broken implement= ations is a better idea than trying to break the working ones. =A0And I am = not just saying this because I=A0successfully=A0use 6to4 on a fairly common= basis ...


/TJ

=A0<= /div>
--0016367658a3d9cd5104a513a6e8-- From gert@space.net Mon Jun 6 23:35:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07A921F85C3 for ; Mon, 6 Jun 2011 23:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppGsQXuRhLC4 for ; Mon, 6 Jun 2011 23:35:07 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.97.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8FF21F85CE for ; Mon, 6 Jun 2011 23:35:07 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 96CF4F81CE for ; Tue, 7 Jun 2011 08:35:05 +0200 (CEST) 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 A781EF8450 for ; Tue, 7 Jun 2011 08:33:36 +0200 (CEST) Received: (qmail 63090 invoked by uid 1007); 7 Jun 2011 08:33:36 +0200 Date: Tue, 7 Jun 2011 08:33:36 +0200 From: Gert Doering To: TJ Message-ID: <20110607063336.GO45955@Space.Net> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.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, ietf@ietf.org, ietf-announce@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 06:35:07 -0000 Hi, On Mon, Jun 06, 2011 at 07:41:49PM -0400, TJ wrote: > On Mon, Jun 6, 2011 at 13:22, Keith Moore wrote: > > > I strongly object to the proposed reclassification of these documents as > > Historic. > > ** > > Agreed that this is too harsh, too soon. Fixing the broken implementations > is a better idea than trying to break the working ones. And I am not just > saying this because I successfully use 6to4 on a fairly common basis ... Do we really need to go through all this again? As long as there is no Internet Overlord that can command people to a) put up relays everywhere and b) ensure that these relays are working, 6to4 as a general mechanism for attachment to the IPv6 Internet is FAIL. If someone wants to use 6to4 to interconnect his machines over an IPv4 infrastructure (=6to4 on both ends), nobody is taking this away. 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 tjc@ecs.soton.ac.uk Tue Jun 7 00:14:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F6C21F8461; Tue, 7 Jun 2011 00:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohu4u9hrJZzl; Tue, 7 Jun 2011 00:14:45 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 918B521F845B; Tue, 7 Jun 2011 00:14:39 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p577EXtl024267; Tue, 7 Jun 2011 08:14:33 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p577EXtl024267 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1307430873; bh=hnxWt52VfGHuyPUsHH3wgY7QVlM=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=QriKM1EjlaLV9H1yEBnVbbpn9lSkIpT9H6d5Xn3i1/DAt+Oa8SxHfqrXJCcfmELvB QWnTPBSx98JNFDKAmv7Zkao/Ku/bRAPPc3A0uLWGpoYVMCfR3DcOifVjGXW7WwHGBw Dx3fPcBOg0rzKO7bKvXHzGZ6WS7cnbHwmu/dXC9E= 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 n568EX0035644059q0 ret-id none; Tue, 07 Jun 2011 08:14:33 +0100 Received: from [192.168.1.14] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p577DE3Y026437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Jun 2011 08:13:15 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Tim Chown In-Reply-To: <20110607063336.GO45955@Space.Net> Date: Tue, 7 Jun 2011 08:13:14 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <20110607063336.GO45955@Space.Net> <4A7A2E91-F290-4DBE-88D0-965443DCECBB@ecs.soton.ac.uk> To: "v6ops@ietf.org WG" , ietf@ietf.org X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n568EX003564405900; tid=n568EX0035644059q0; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p577EXtl024267 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 07:14:48 -0000 On 7 Jun 2011, at 07:33, Gert Doering wrote: >=20 > Do we really need to go through all this again? >=20 > As long as there is no Internet Overlord that can command people to=20 > a) put up relays everywhere and b) ensure that these relays are = working, > 6to4 as a general mechanism for attachment to the IPv6 Internet is = FAIL. >=20 > If someone wants to use 6to4 to interconnect his machines over an IPv4 > infrastructure (=3D6to4 on both ends), nobody is taking this away. >=20 > Gert Doering > -- NetMaster Exactly. Less than 1% of the IPv6 traffic reaching us is 6to4. And 6to4 in its = 6to4-to-native mode is proven to be highly unreliable. It seems highly = preferable to have that 1% wait for native IPv6 to be available to them, = rather than being used as a reason by the bigger content providers for = holding back production deployment, which is what we all want to see. It's time to remove the stabilisers on the IPv6 bicycle. Tim From ichiroumakino@gmail.com Tue Jun 7 01:48:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BAA1F0C35; Tue, 7 Jun 2011 01:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 645qfJMq2s6m; Tue, 7 Jun 2011 01:48:47 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0843F1F0C34; Tue, 7 Jun 2011 01:48:46 -0700 (PDT) Received: by wyb29 with SMTP id 29so4024498wyb.31 for ; Tue, 07 Jun 2011 01:48:46 -0700 (PDT) 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=SeRlIB/r8mp454KCGU8vdOzabz9UYzFOk8DW4GHxlJ0=; b=rWMzXzM7CKOYA7FX3/Mcg6DSQrjIfQwMmIRIzykfppIr9XxoXXbwrkNSu52MVB0lCM G3eUFsd2WkDodnbof3gptFcE38XUinX6H47MgYSphbt18S5vCynhHRseTO/PxPLDfchr 9aHm+hWCu1pv0XHHEFLEJszYG3lDgSfejicyM= 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=tWR4ZdvdMgo8QIvoimSA6myybSGlX1bHVTXRk1Sb7Wg6i2bnSp7Eg4gyFTu9KpUKk7 szNL5XvujIvBVmySIPMCNae1OJGz3UT7GA6T1Tkhasjpnn4nhKNPFZXoyTjvgu/VrlNV Pq/HLPR22Q5ZHKOybE3uGZiDr9SjQ6JvVF7Bc= Received: by 10.227.160.140 with SMTP id n12mr5814286wbx.69.1307436526136; Tue, 07 Jun 2011 01:48:46 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-213.cisco.com (dhcp-osl-vl300-64-103-53-213.cisco.com [64.103.53.213]) by mx.google.com with ESMTPS id fl19sm1511630wbb.15.2011.06.07.01.48.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Jun 2011 01:48:45 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Tue, 7 Jun 2011 10:48:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Working Group , ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 08:48:48 -0000 Keith, I'm loathe to go through this discussion again. let me just respond to = some of the points you make, and then agree that we disagree. > I strongly object to the proposed reclassification of these documents = as Historic. =20 >=20 > 6to4 still has many valid use cases, and there is not a suitable = replacement for it that has been deployed. Until there is a suitable = replacement, or until there is widespread ISP support for native IPv6, = reclassification of this document to Historic is premature. (6rd is not = a suitable replacement for 6to4, as it is intended for very different = use cases than 6to4.) >=20 > (It could be argued that reclassification of RFC 3068 (by itself) to = Historic is appropriate, but that would require a separate document and = last call.) >=20 > In addition, this document is misleading and perhaps even = vituperative. For instance: >=20 > "There would appear to be no evidence of any substantial deployment of = the variant of 6to4 described in [RFC3056]." > This statement is blatantly false. 6to4 is supported by every major = desktop and server platfrom that is shipping today, and has been = supported for several years. incorrect. there is no evidence that the _managed_ model of 6to4 = described in rfc3056 has any deployment. that's the model where relay operators advertise what parts of the 6to4 = space they are routing. with BGP neighborships between managed and = participating relays. _deployment_ not _support_. > "The IETF sees no evolutionary future for the mechanism and it is not = recommended to include this mechanism in new implementations." >=20 > 6to4 never was intended to have an "evolutionary future". It was = always intended as a near-term solution to allow consenting hosts and = networks to interchange IPv6 traffic without prior support from the IPv4 = networks that carry the traffic. It is premature to recommend that = 6to4 be removed from implementations. We do not know how long it will = take ISPs to universally deploy IPv6. Until they do, there will be a = need for individuals and enterprises using IPv6-based applications to be = able to exchange IPv6 traffic with hosts that only have IPv4 = connectivity. =20 >=20 > All of the criticisms in section 3 have to do with the use of relays = to exchange traffic between 6to4 and native IPv6. In many cases the = criticisms are overbroad. Not all uses of 6to4 involve relays. For = some of those that do need to use relays, it is not necessarily the case = that the relay is operated by an unknown third-party. =20 >=20 > The fact that some firewalls block protocol 41 traffic causes problems = for many tunneling solutions, not just 6to4; yet this document appears = to recommend some tunneling solutions while trashing 6to4. it is the unmanaged aspect of 6to4 deployment that exhibits the most = problems. a manually configured managed point to point tunnel may also = be blocked in a firewall, but then the operator will have to sort that = out. 6to4 has no operator. Teredo is similar in many aspects to 6to4, but there is little evidence = that it causes the same problems. largely because it is the choice of = last resort in implementations and it hasn't/can't be enabled by default = in CPEs. > The recommendations to treat 6to4 as a service of last resort will do = harm to users and applications using it. A better recommendation is = for hosts to disable 6to4 by default. =20 >=20 > This document appears to make the mistake of assuming that the purpose = of applications using IPv6 is to interoperate with the existing = Internet. I have maintained for many years that it is new applications, = or existing applications that can't tolerate widespread deployment of = IPv4 NAT, that will drive use of IPv6. I therefore believe that it is = inappropriate to judge 6to4 merely by how well it works in scenarios = where it is being used to talk to applications that work well over IPv4 = NAT such as HTTP. The Internet is much more diverse than that, and = will become even more diverse as IPv6 enjoys wider deployment. 6to4 does not work through IPv4 NATs. > It is also premature to remove references to 6to4 from RFC 5156bis, = for IANA to mark the prefix and DNS zones as deprecated. This will only = cause confusion and difficulty for legitimate continued uses of 6to4. the purpose of the text in the document is to ensure that the deprecated = prefixes are not reused before 6to4 has been phased out. cheers, Ole= From trejrco@gmail.com Tue Jun 7 04:33:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD1A21F84E2; Tue, 7 Jun 2011 04:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEK1MAkVcp5Q; Tue, 7 Jun 2011 04:33:31 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9D6421F84DE; Tue, 7 Jun 2011 04:33:30 -0700 (PDT) Received: by gyf3 with SMTP id 3so2569294gyf.31 for ; Tue, 07 Jun 2011 04:33:30 -0700 (PDT) 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; bh=hT6M2iUs77ri4r/e2jW5x2boadH11Z4hxL02gjAVz20=; b=whFjP933rrH5B9HYQFaXkQnNv7grc4s6liSGUM+Nhy2jddgtAyrMJSKu4QynBTGzAQ JnZNMLL5v4d02XT8N3KxRdYkWrIBmyOPNUJGQEWw/8P2g2kw7oYMnKFBaWxGHZbrbkBp 4V/tNpslQJm1Tyyk0JS7wEgbszjUECmEHhg30= 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; b=A5EOhsF0l4j8jZIVsvdJPb+r5OMGj5EozZB6zjNzn00UE2w+f4/E2qOWG1MfE++CTv uFfc0+a8CA3vMjywfuY0QuLiJkKaNAQTA96UnO9c0DwAJ/wQI7rc501/ErXt/xJEq+6H xwn4rIYG4IBxRS6qNW3DgiYCRGclSnHOaklrI= MIME-Version: 1.0 Received: by 10.91.195.5 with SMTP id x5mr2648775agp.103.1307446410048; Tue, 07 Jun 2011 04:33:30 -0700 (PDT) Received: by 10.91.170.3 with HTTP; Tue, 7 Jun 2011 04:33:28 -0700 (PDT) Received: by 10.91.170.3 with HTTP; Tue, 7 Jun 2011 04:33:28 -0700 (PDT) In-Reply-To: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <4A7A2E91-F290-4DBE-88D0-965443DCECBB@ecs.soton.ac.uk> <20110607063336.GO45955@Space.Net> Date: Tue, 7 Jun 2011 07:33:28 -0400 Message-ID: From: TJ To: Tim Chown Content-Type: multipart/alternative; boundary=00163676587dd576ad04a51d964a Cc: "v6ops@ietf.org WG" , ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: trejrco@gmail.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 11:33:31 -0000 --00163676587dd576ad04a51d964a Content-Type: text/plain; charset=ISO-8859-1 > Less than 1% of the IPv6 traffic reaching us is 6to4. Unless you provide IPv6 only sites, you should see very little ... that is part of the point :). > It's time to remove the stabilisers on the IPv6 bicycle. I agree, but get me native everywhere before taking away one connection mechanism that does work. Just my $.02, /TJ ... ready for world IPv6 Day? --00163676587dd576ad04a51d964a Content-Type: text/html; charset=ISO-8859-1


> Less than 1% of the IPv6 traffic reaching us is 6to4.

Unless you provide IPv6 only sites, you should see very little ... that is part of the point :).

<snip>

> It's time to remove the stabilisers on the IPv6 bicycle.

I agree, but get me native everywhere before taking away one connection mechanism that does work.

Just my $.02,
/TJ ... ready for world IPv6 Day?

--00163676587dd576ad04a51d964a-- From wesley.george@twcable.com Tue Jun 7 05:56:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127C911E8102; Tue, 7 Jun 2011 05:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVGXiwAdruyV; Tue, 7 Jun 2011 05:56:30 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 53C9211E80C0; Tue, 7 Jun 2011 05:56:30 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,332,1304308800"; d="scan'208";a="221653942" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 07 Jun 2011 08:56:35 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Tue, 7 Jun 2011 08:56:29 -0400 From: "George, Wesley" To: "trejrco@gmail.com" Date: Tue, 7 Jun 2011 08:56:27 -0400 Thread-Topic: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC Thread-Index: AcwlBs60NNUHtNEPRnGN4Wu0BHZ3iwACmjLQ Message-ID: <34E4F50CAFA10349A41E0756550084FB067B72F8@PRVPEXVS04.corp.twcable.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <4A7A2E91-F290-4DBE-88D0-965443DCECBB@ecs.soton.ac.uk> <20110607063336.GO45955@Space.Net> 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 WG" , "ietf@ietf.org" Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 12:56:31 -0000 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of T= J Sent: Tuesday, June 07, 2011 7:33 AM To: Tim Chown Cc: v6ops@ietf.org WG; ietf@ietf.org Subject: Re: [v6ops] Last Call: = (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Histo= ric status) to Informational RFC > It's time to remove the stabilisers on the IPv6 bicycle. I agree, but get me native everywhere before taking away one connection mec= hanism that does work. This takes nothing away. It's not as if the day that this draft gets publis= hed as an RFC, 6to4 stops working. IETF has moved other protocols to histor= ical status before they were out of heavy use, with the expectation that it= would take some time for the alternatives to be deployed and existing impl= ementations to be retired. This is specifically why we resisted the idea of= putting in a shutdown schedule or other flag day where the 6to4 prefixes g= et null-routed, because it's likely to be different in each network and app= lication. "In order to limit the impact of end-users, it is recommended that operators retain their existing 6to4 relay routers and follow the recommendations found in [I-D.ietf-v6ops-6to4-advisory]. When traffic levels diminish, these routers can be decommissioned." Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From fernando.gont.netbook.win@gmail.com Tue Jun 7 06:32:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E1011E8101; Tue, 7 Jun 2011 06:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbodLpky5zOb; Tue, 7 Jun 2011 06:31:59 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 556CA11E808E; Tue, 7 Jun 2011 06:31:59 -0700 (PDT) Received: by gxk19 with SMTP id 19so2638489gxk.31 for ; Tue, 07 Jun 2011 06:31:58 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=Gs/07prDImCcX7YegUVdeujV3T0/S0uzggVg7GZJej0=; b=NUF+z20w5mwP4OXwXwKEBZf9WFcgCGFnpzKkkFGNodHPEQzbtieJkN4DuR7Ic4ZU6R btg6xBbwkEAN50xEySR4YpTNUJwAxmtTcTbDYyUEd+Hlm6orz1XL7UOZnuqQOC9Nrfyy I3LkbuK0/C3Rf4OuQko4dtsSATv2N5xgqtfwI= 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:content-type :content-transfer-encoding; b=c71AKdoXA6PEXOwiqk4ueAoH3jPSqvbdAppM70USwO9/HW2UcAoqC05P8ELegsHw2P 6Oe2SWgeJJSvpuJgra1Duidj6/KI97UqInoTptUhB4vSCqT+NIDNYLYBo/0ZMZnu9Alm eb7Uyy+putwYdU1pePgKDSvUIZtzPmllzM0GE= Received: by 10.101.2.25 with SMTP id e25mr4862704ani.28.1307453518777; Tue, 07 Jun 2011 06:31:58 -0700 (PDT) Received: from [192.168.1.102] ([190.190.97.123]) by mx.google.com with ESMTPS id w19sm4069026anf.38.2011.06.07.06.31.52 (version=SSLv3 cipher=OTHER); Tue, 07 Jun 2011 06:31:57 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DED7DB2.6080802@gont.com.ar> Date: Mon, 06 Jun 2011 22:24:02 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Leslie References: <4DEA6323.4070302@cs.tcd.ie> <20110605031045.GK88250@verdi> In-Reply-To: <20110605031045.GK88250@verdi> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ipv6@ietf.org, Eliot Lear , "saag@ietf.org" , "Turner, Sean P." , Stephen Farrell Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 13:32:00 -0000 On 06/05/2011 12:10 AM, John Leslie wrote: >> I think we'd like to respond to them that that's great, >> and we'll be interested in their results, but can they >> *please* come back to us before saying something should >> be changed so's we can talk about it. > > I don't think that's quite right. We should welcome their studying > security issues; but I think we need to _strongly_ encourage them to > start from draft-ietf-6man-node-req-bis when it becomes an RFC -- since > it has _significant_ changes from RFC 4294 (and an ITU-T study based > on RFC4294 will be of rather limited value). While I have not read the latest version of the aforementioned I-D, I don't think it address (nor should it) the security implications of IPv6. As a simply example, while there has been some work on the security implications of transition/co-existence technologies, I don't think there have been e.g. best practices published on e.g. how to filter them (in those environments in which the use of technologies such as Teredo is undesirable). Additionally, I don't think there has been much work on which tools could be used (and how) to perform network monitoring (e.g., use NDPMon to monitor ND-based attacks). > Clearly, ITU-T is entirely justified in publishing recommendations > of what level of security-related-trust to place in IPv6 packet > forwarding: but any protocol _changes_ are outside their bailiwick. Agreed. However (and with no clue about what ITU-T is planning to work on) I guess there's room for recommendations on what stuff to filter, specific features that should be enabled/disabled, etc. > (As an aside, IETF should resist most proposals for change until > IPv6 sees widespread deployment -- deploying to a moving target is > just TOO risky.) While I do see some value in this point (and I'm aware there are many that share this point of view), I think this argument does not necessarily apply to security. If a flaw is identified, and there's a concrete proposal to mitigate it, I don't think it would be a good idea to resist to *this* type of change/update. 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 trejrco@gmail.com Tue Jun 7 06:35:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC0D21F84A6; Tue, 7 Jun 2011 06:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cj8xN+PO25OY; Tue, 7 Jun 2011 06:35:22 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B94621F8492; Tue, 7 Jun 2011 06:35:22 -0700 (PDT) Received: by yib18 with SMTP id 18so1473188yib.31 for ; Tue, 07 Jun 2011 06:35:21 -0700 (PDT) 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 :from:date:message-id:subject:to:content-type; bh=8aKWC7bSwg+hxOrMsCJARTOhVaEUfEPOpOJxsJ3EzjE=; b=x5z3KZuWiQC0ZQk2c2uaJpqJEG0572ovrXh5QxT3SZxxwh/kZDcmZ6rGNIhfpFB3eZ orXfgrwCFFi5G0pEqa8dFxSJTGHMIPP+6+MEjgDOqp9JFZXiAnswciTEejwRcl3j6WHN /bt/REWgHBP5+xpSi9QEU4a7Ack6sybWY+OLM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type; b=HYVXAnCNKnWLVH1aNt03m9O6ILHFbsWqXHZKrGB10YpepcRB/iiQccHwX8SjLuPras +hRRDKr5Cv81PRCkYJEvI4o4Rh2OUm6rnBMHU2ZrGR+1H6fW+DizhgJM5ZVKzizT1B+P hLE1c741b61mTy5FKIDvcAHndiDAMsZlSPePA= Received: by 10.90.61.8 with SMTP id j8mr5552420aga.76.1307453721613; Tue, 07 Jun 2011 06:35:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.170.3 with HTTP; Tue, 7 Jun 2011 06:34:59 -0700 (PDT) In-Reply-To: <34E4F50CAFA10349A41E0756550084FB067B72F8@PRVPEXVS04.corp.twcable.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <4A7A2E91-F290-4DBE-88D0-965443DCECBB@ecs.soton.ac.uk> <20110607063336.GO45955@Space.Net> <34E4F50CAFA10349A41E0756550084FB067B72F8@PRVPEXVS04.corp.twcable.com> From: TJ Date: Tue, 7 Jun 2011 09:34:59 -0400 Message-ID: To: "George, Wesley" , "v6ops@ietf.org WG" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=0016e68db78ca317bc04a51f4a26 Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: trejrco@gmail.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 13:35:23 -0000 --0016e68db78ca317bc04a51f4a26 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 7, 2011 at 08:56, George, Wesley wrote: > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > TJ > Sent: Tuesday, June 07, 2011 7:33 AM > To: Tim Chown > Cc: v6ops@ietf.org WG; ietf@ietf.org > Subject: Re: [v6ops] Last Call: > (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to > Historic status) to Informational RFC > > > It's time to remove the stabilisers on the IPv6 bicycle. > I agree, but get me native everywhere before taking away one connection > mechanism that does work. > > > This takes nothing away. It's not as if the day that this draft gets > published as an RFC, 6to4 stops working. IETF has moved other protocols to > historical status before they were out of heavy use, with the expectation > that it would take some time for the alternatives to be deployed and > existing implementations to be retired. This is specifically why we resisted > the idea of putting in a shutdown schedule or other flag day where the 6to4 > prefixes get null-routed, because it's likely to be different in each > network and application. > > "In order to limit the impact of end-users, it is > recommended that operators retain their existing 6to4 relay routers > and follow the recommendations found in > [I-D.ietf-v6ops-6to4-advisory]. When traffic levels diminish, these > routers can be decommissioned." > > Wes George > > I agree with the end goal here, but for a mechanism that relies on the good will of others (relays) changing it to "historic" could have a more-abrupt impact on those who use the mechanism than in other cases of similar demotions. That is my concern. /TJ --0016e68db78ca317bc04a51f4a26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 7, 2011 at 08:56, George, Wesley= <wesley.= george@twcable.com> wrote:

From: v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of TJ
Sent: Tuesday, June 07, 2011 7:33 AM
To: Tim Chown
Cc: v6ops@ietf.org WG; ietf@ietf.org
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.tx= t> (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to= Historic status) to Informational RFC

> It's time to remove the stabilisers on the IPv6 bicycle.
I agree, but get me native everywhere before taking away one connection mec= hanism that does work.


This takes nothing away. It's not as if the day that this draft g= ets published as an RFC, 6to4 stops working. IETF has moved other protocols= to historical status before they were out of heavy use, with the expectati= on that it would take some time for the alternatives to be deployed and exi= sting implementations to be retired. This is specifically why we resisted t= he idea of putting in a shutdown schedule or other flag day where the 6to4 = prefixes get null-routed, because it's likely to be different in each n= etwork and application.

"In order to limit the impact of end-users, it is
=A0 recommended that operators retain their existing 6to4 relay routers =A0 and follow the recommendations found in
=A0 [I-D.ietf-v6ops-6to4-advisory]. =A0When traffic levels diminish, these=
=A0 routers can be decommissioned."

Wes George


I agree with the end goa= l here, but for a mechanism that relies on the good will of others (relays)= changing it to "historic" could have a more-abrupt impact on tho= se who use the mechanism than in other cases of similar demotions. =A0That = is my concern.

=A0/TJ
--0016e68db78ca317bc04a51f4a26-- From cb.list6@gmail.com Tue Jun 7 06:58:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E4A11E808E; Tue, 7 Jun 2011 06:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeOl0B19OYcn; Tue, 7 Jun 2011 06:58:35 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD6A11E80F0; Tue, 7 Jun 2011 06:58:35 -0700 (PDT) Received: by wwa36 with SMTP id 36so3340345wwa.13 for ; Tue, 07 Jun 2011 06:58:34 -0700 (PDT) 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=FPmSggJEpIbFwoT8dpNTDDr8CGt1aAOy7G42OaPsIuw=; b=IYsl1TIwT6XPRc/K7ay6HY3TLEtbIERVIWXk9PzkDWs/7NMWjjmXmRVQT0OdRtAbvY 7EcQqEZ4CPNvobc0YVYKwKs3iarnRDMNHrZhaiyPWoHDM9mqPnIZN8OLVwXhy0qw30Mo l3e9Z2Z02voGd51hhqAEjJZi9uscE+QxrkPvk= 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=lbOn+W2cJXjr6QTjPMkfw0LDaHu+Zfch2bgBM99JXVrftcCzu/a/YNkZl2Tjv5hPyK 3k9HfLJaUjMVniZznhRDxk53HBUS4ILjbV0TA4NejLA/JvLiTWdopRR13M9TiFq/yUYQ mH+3CEbyL4RnfkdrekKnS0zqndi1H2Lq3mZAo= MIME-Version: 1.0 Received: by 10.216.241.132 with SMTP id g4mr2041569wer.9.1307455114179; Tue, 07 Jun 2011 06:58:34 -0700 (PDT) Received: by 10.216.179.199 with HTTP; Tue, 7 Jun 2011 06:58:34 -0700 (PDT) Received: by 10.216.179.199 with HTTP; Tue, 7 Jun 2011 06:58:34 -0700 (PDT) In-Reply-To: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <4A7A2E91-F290-4DBE-88D0-965443DCECBB@ecs.soton.ac.uk> <20110607063336.GO45955@Space.Net> Date: Tue, 7 Jun 2011 06:58:34 -0700 Message-ID: From: Cameron Byrne To: Tim Chown Content-Type: multipart/alternative; boundary=e0cb4e43d1b9a3f4fb04a51f9d41 Cc: "v6ops@ietf.org WG" , ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 13:58:39 -0000 --e0cb4e43d1b9a3f4fb04a51f9d41 Content-Type: text/plain; charset=ISO-8859-1 On Jun 7, 2011 12:16 AM, "Tim Chown" wrote: > > > On 7 Jun 2011, at 07:33, Gert Doering wrote: > > > > > Do we really need to go through all this again? > > > > As long as there is no Internet Overlord that can command people to > > a) put up relays everywhere and b) ensure that these relays are working, > > 6to4 as a general mechanism for attachment to the IPv6 Internet is FAIL. > > > > If someone wants to use 6to4 to interconnect his machines over an IPv4 > > infrastructure (=6to4 on both ends), nobody is taking this away. > > > > Gert Doering > > -- NetMaster > > Exactly. > > Less than 1% of the IPv6 traffic reaching us is 6to4. And 6to4 in its 6to4-to-native mode is proven to be highly unreliable. It seems highly preferable to have that 1% wait for native IPv6 to be available to them, rather than being used as a reason by the bigger content providers for holding back production deployment, which is what we all want to see. > > It's time to remove the stabilisers on the IPv6 bicycle. > +1. Let's move on and not repeat this tired discussion. Cb > Tim > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --e0cb4e43d1b9a3f4fb04a51f9d41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jun 7, 2011 12:16 AM, "Tim Chown" <tjc@ecs.soton.ac.uk> wrote:
>
>
> On 7 Jun 2011, at 07:33, Gert Doering wrote:
>
> >
> > Do we really need to go through all this again?
> >
> > As long as there is no Internet Overlord that can command people = to
> > a) put up relays everywhere and b) ensure that these relays are w= orking,
> > 6to4 as a general mechanism for attachment to the IPv6 Internet i= s FAIL.
> >
> > If someone wants to use 6to4 to interconnect his machines over an= IPv4
> > infrastructure (=3D6to4 on both ends), nobody is taking this away= .
> >
> > Gert Doering
> > =A0 =A0 =A0 =A0-- NetMaster
>
> Exactly.
>
> Less than 1% of the IPv6 traffic reaching us is 6to4. And 6to4 in its = 6to4-to-native mode is proven to be highly unreliable. It seems highly pref= erable to have that 1% wait for native IPv6 to be available to them, rather= than being used as a reason by the bigger content providers for holding ba= ck production deployment, which is what we all want to see.
>
> It's time to remove the stabilisers on the IPv6 bicycle.
>

+1. Let's move on and not repeat this tired discussion.=A0

Cb

> Tim
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--e0cb4e43d1b9a3f4fb04a51f9d41-- From wesley.george@twcable.com Tue Jun 7 07:39:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCD321F8446; Tue, 7 Jun 2011 07:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh7Tkj99sWIr; Tue, 7 Jun 2011 07:39:53 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4BC21F8441; Tue, 7 Jun 2011 07:39:53 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,332,1304308800"; d="scan'208";a="235240644" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 07 Jun 2011 10:46:52 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 7 Jun 2011 10:39:52 -0400 From: "George, Wesley" To: Keith Moore , "ietf@ietf.org" Date: Tue, 7 Jun 2011 10:39:51 -0400 Thread-Topic: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC Thread-Index: Acwkbm4HzRgmGLCeQW6rooVHG8gmQQAo1VsQ Message-ID: <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.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" Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:39:54 -0000 At the risk of rehashing discussion from WGLC... Ole has addressed some of your points, I'll address a few others below inli= ne. From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of K= eith Moore Sent: Monday, June 06, 2011 1:22 PM To: ietf@ietf.org Cc: v6ops@ietf.org; IETF-Announce Subject: Re: [v6ops] Last Call: = (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Histo= ric status) to Informational RFC 6to4 still has many valid use cases, and there is not a suitable replacemen= t for it that has been deployed. Until there is a suitable replacement, or= until there is widespread ISP support for native IPv6, reclassification of= this document to Historic is premature. (6rd is not a suitable replacemen= t for 6to4, as it is intended for very different use cases than 6to4.) WEG> Please substantiate these claims. What are the use cases, and why are = there no other solutions for those specific use cases? What is considered "= widespread ISP support for native IPV6"? "The IETF sees no evolutionary future for the mechanism and it is not recom= mended to include this mechanism in new implementations." 6to4 never was intended to have an "evolutionary future". It was always in= tended as a near-term solution to allow consenting hosts and networks to in= terchange IPv6 traffic without prior support from the IPv4 networks that ca= rry the traffic. It is premature to recommend that 6to4 be removed from i= mplementations. We do not know how long it will take ISPs to universally d= eploy IPv6. Until they do, there will be a need for individuals and enterp= rises using IPv6-based applications to be able to exchange IPv6 traffic wit= h hosts that only have IPv4 connectivity. WEG> As was discussed in the WGLC for this document, enterprise application= s will not realistically use 6to4 as a means to reach IPv6 for business cri= tical applications. It's simply not reliable enough. It's also probably unl= ikely that those will go directly to IPv6-only vs using dual-stack to ease = that transition. Individuals and Enterprises that use IPv6-only application= s will need to make IPv6 service a non-negotiable requirement for their ISP= s, networks, and devices rather than hoping that 6to4 works. All of the criticisms in section 3 have to do with the use of relays to exc= hange traffic between 6to4 and native IPv6. In many cases the criticisms = are overbroad. Not all uses of 6to4 involve relays. For some of those th= at do need to use relays, it is not necessarily the case that the relay is = operated by an unknown third-party. WEG> Again, please substantiate this with examples of implementations that = are actively using non-relay 6to4. Also, the number of applications of 6to4= that can be guaranteed to avoid any unknown 3rd party relays is extremely = limited due to the nature of anycast and 6to4's asymmetric routing. The pro= tocol action requested in this draft in no way prevents one or more consent= ing networks from using 6to4 and continuing to run relays for their local t= raffic indefinitely - in fact, it even provides a reference to a document t= o show them how to make it work as well as possible. It is simply saying th= at it's not a good idea. The recommendations to treat 6to4 as a service of last resort will do harm = to users and applications using it. A better recommendation is for hosts = to disable 6to4 by default. WEG> this seems to be to be splitting hairs. Please explain the distinction= you're making here. Disable by default means never use. Use as last resort= means use when no better IP connectivity is available. I would think if yo= u insist that 6to4 must stick around you'd prefer it to be enabled. I under= stand that there are different values of "better" but if 6to4 works, this m= eans that the host is not behind a NAT, and therefore by most definitions, = its IPv4 connectivity would be better than 6to4. If it's behind an IPv4 NAT= , and therefore IPv6 connectivity would be better (especially if there are = one or more applications that work via IPv6 but not via IPv4 + NAT) then 6t= o4 won't work in lieu of IPv6 connectivity anyway. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From moore@network-heretics.com Tue Jun 7 08:21:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7F121F8494; Tue, 7 Jun 2011 08:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv0YzwTTSUW1; Tue, 7 Jun 2011 08:21:16 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id A0AB121F848E; Tue, 7 Jun 2011 08:21:12 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id B586E20248; Tue, 7 Jun 2011 11:21:08 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 07 Jun 2011 11:21:08 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=rjU89i/thnBE82B8ACtt5TXATMc=; b=PHFgleuHen2/Ve8q8Z0JSLJfR/Z0j8h80xymlbyCi+6+RX03NzezonJUnlKaD+GDpBM0oSxC6xlHw5OgZWZlVGv6MFy/GhEYXE0R+rAgoVRzuiSMhGPx/LvUVs8YLMiUL/SgvQCSuP0XIO6mYsN2hZp1GO4JuW2wZN1S0OMWxC8= X-Sasl-enc: 9eFlCh9xSSQp/+uqkgdBtildedmoAs0jqHjrap/d+jyj 1307460066 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 65FA3403D22; Tue, 7 Jun 2011 11:21:06 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-11-587867425 From: Keith Moore In-Reply-To: <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> Date: Tue, 7 Jun 2011 11:21:05 -0400 Message-Id: <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> To: "George, Wesley" X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , "ietf@ietf.org" Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:21:22 -0000 --Apple-Mail-11-587867425 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 7, 2011, at 10:39 AM, George, Wesley wrote: > At the risk of rehashing discussion from WGLC... > Ole has addressed some of your points, I'll address a few others below = inline. >=20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Keith Moore > Sent: Monday, June 06, 2011 1:22 PM > To: ietf@ietf.org > Cc: v6ops@ietf.org; IETF-Announce > Subject: Re: [v6ops] Last Call: = (Request to move Connection = of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to = Informational RFC >=20 > 6to4 still has many valid use cases, and there is not a suitable = replacement for it that has been deployed. Until there is a suitable = replacement, or until there is widespread ISP support for native IPv6, = reclassification of this document to Historic is premature. (6rd is not = a suitable replacement for 6to4, as it is intended for very different = use cases than 6to4.) >=20 > WEG> Please substantiate these claims. What are the use cases, and why = are there no other solutions for those specific use cases? What is = considered "widespread ISP support for native IPV6"? The best current use cases for 6to4 that I'm aware of are: - Applications developers want to be forward thinking and develop IPv6 = apps, but cannot get native IPv6 access. 6to4 allows them to develop = those apps and test or use them in useful situations (i.e. outside of a = lab) without having to configure a separate tunnel to every host = involved. Note that 6to4 is useful in this way even if all of the = addresses used are 6to4 addresses, and the traffic therefore does not = cross any relays between 6to4 and native IPv6. - Enterprises have applications that need to be able to communicate with = large numbers of hosts spread over a diverse area. IPv6 is clearly the = way that they want to go, but it's not widely available at present. = 6to4 provides them with a means of routing traffic to their hosts in the = interim until widespread support for IPv6 exists. - Users (including enterprise users) who have small networks with IPv4 = access (generally behind v4 NATs) can use 6to4 to allow them to remotely = access individual hosts on those networks. This can be done either with = a NAT that also acts as a v6 router and supports 6to4 as an external = connection, or by configuring the NAT to pass protocol 41 to a IPv6 = router for the network, internal to the v4 NAT. Widespread IPv6 support for native IPv6 would be when native IPv6 is = available everywhere that IPv4 access is available, from at least one = provider, with quality (connectivity, reliability, support) = approximately as good as IPv4, and at a reasonable price. In other = words, you can't expect applications to rely on native IPv6 until it's = reliably available everywhere that they need to use it. > "The IETF sees no evolutionary future for the mechanism and it is not = recommended to include this mechanism in new implementations." >=20 > 6to4 never was intended to have an "evolutionary future". It was = always intended as a near-term solution to allow consenting hosts and = networks to interchange IPv6 traffic without prior support from the IPv4 = networks that carry the traffic. It is premature to recommend that = 6to4 be removed from implementations. We do not know how long it will = take ISPs to universally deploy IPv6. Until they do, there will be a = need for individuals and enterprises using IPv6-based applications to be = able to exchange IPv6 traffic with hosts that only have IPv4 = connectivity. >=20 > WEG> As was discussed in the WGLC for this document, enterprise = applications will not realistically use 6to4 as a means to reach IPv6 = for business critical applications. It's simply not reliable enough. = It's also probably unlikely that those will go directly to IPv6-only vs = using dual-stack to ease that transition. Individuals and Enterprises = that use IPv6-only applications will need to make IPv6 service a = non-negotiable requirement for their ISPs, networks, and devices rather = than hoping that 6to4 works. With respect, the v6ops working group is not in a good position to judge = whether enterprise applications will use 6to4. Operators rarely have a = good understanding of what individual application users or developers = need. They tend to focus mostly on the applications that generate the = most traffic, or cause them particular amounts of trouble, or the ones = that their biggest customers need. Problem is, those aren't the only = applications that are important. Every application is important to its = users, no matter how much or little traffic (or revenue) it generates. 6to4 is as reliable as IPv4 is, if it isn't asked to cross a relay = router. And there are valid reasons to use 6to4 even where IPv4 = connectivity already exists. Even in cases where 6to4 traffic must cross a relay router, sometimes = it's the best solution available. =20 > All of the criticisms in section 3 have to do with the use of relays = to exchange traffic between 6to4 and native IPv6. In many cases the = criticisms are overbroad. Not all uses of 6to4 involve relays. For = some of those that do need to use relays, it is not necessarily the case = that the relay is operated by an unknown third-party. >=20 > WEG> Again, please substantiate this with examples of implementations = that are actively using non-relay 6to4. Also, the number of applications = of 6to4 that can be guaranteed to avoid any unknown 3rd party relays is = extremely limited due to the nature of anycast and 6to4's asymmetric = routing. The protocol action requested in this draft in no way prevents = one or more consenting networks from using 6to4 and continuing to run = relays for their local traffic indefinitely - in fact, it even provides = a reference to a document to show them how to make it work as well as = possible. It is simply saying that it's not a good idea. Application implementations shouldn't care whether they're using relay = 6to4, non-relay 6to4, or 6to4 at all. Application implementations = should at most care that they're using IPv6 rather than IPv4, and for = some applications even this is not appropriate. Application deployments might well need to care how well their = underlying networks work. Ideally, they shouldn't have to care, but = that's the world we're currently living in. The requested protocol action deprecates 6to4 and discourages its = inclusion in future implementations. That's harmful to applications and = users for whom native IPv6 isn't available - which is to say, pretty = much everyone at the moment. When native IPv6 becomes widely available, = it will then be appropriate to transition hosts and networks using 6to4 = to native IPv6. But even then, there will probably still be a need for = host implementations=20 > The recommendations to treat 6to4 as a service of last resort will do = harm to users and applications using it. A better recommendation is = for hosts to disable 6to4 by default. >=20 > WEG> this seems to be to be splitting hairs. Please explain the = distinction you're making here. Disable by default means never use. Use = as last resort means use when no better IP connectivity is available. I was interpreting "treat 6to4 as a service of last resort" as affecting = the address and interface selection algorithm. If 6to4 is enabled on a = host or network, there are reasons to use 6to4 in preference to some = other kinds of connectivity. The question of whether to enable 6to4 = should be separate from the question of "if 6to4 is enabled, what = priority should it have in address selection?" Keith p.s. I'd support the writing of an applicability statement for 6to4 that = recommends a narrowing of its applicability to specific use cases, and = I'm even willing to help write it. But moving it to Historic is going = too far, and it sends the wrong message. We need for 6to4 in our = toolbox to enable enterprises and applications developers to be able to = write and (tentatively, carefully) deploy applications that use IPv6. = We can't afford to wait until all ISPs support native v6 for people to = start writing applications that use it. =20 --Apple-Mail-11-587867425 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
At = the risk of rehashing discussion from WGLC...
Ole has addressed some = of your points, I'll address a few others below inline.

From: v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of Keith Moore
Sent: = Monday, June 06, 2011 1:22 PM
To: ietf@ietf.org
Cc: v6ops@ietf.org; = IETF-Announce
Subject: Re: [v6ops] Last Call: = <draft-ietf-v6ops-6to4-to-historic-04.txt> (Request to move = Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to = Informational RFC

6to4 still has many valid use cases, and there = is not a suitable replacement for it that has been deployed.  Until = there is a suitable replacement, or until there is widespread ISP = support for native IPv6, reclassification of this document to Historic = is premature.  (6rd is not a suitable replacement for 6to4, as it = is intended for very different use cases than 6to4.)

WEG> = Please substantiate these claims. What are the use cases, and why are = there no other solutions for those specific use cases? What is = considered "widespread ISP support for native = IPV6"?

The best current use = cases for 6to4 that I'm aware of are:

- = Applications developers want to be forward thinking and develop IPv6 = apps, but cannot get native IPv6 access.  6to4 allows them to = develop those apps and test or use them in useful situations (i.e. = outside of a lab) without having to configure a separate tunnel to every = host involved.   Note that 6to4 is useful in this way even if all = of the addresses used are 6to4 addresses, and the traffic therefore does = not cross any relays between 6to4 and native IPv6.
- = Enterprises have applications that need to be able to communicate with = large numbers of hosts spread over a diverse area.  IPv6 is clearly = the way that they want to go, but it's not widely available at present. =  6to4 provides them with a means of routing traffic to their hosts = in the interim until widespread support for IPv6 exists.
- = Users (including enterprise users) who have small networks with IPv4 = access (generally behind v4 NATs) can use 6to4 to allow them to remotely = access individual hosts on those networks.  This can be done either = with a NAT that also acts as a v6 router and supports 6to4 as an = external connection, or by configuring the NAT to pass protocol 41 to a = IPv6 router for the network, internal to the v4 = NAT.

Widespread IPv6 support for native IPv6 would = be when native IPv6 is available everywhere that IPv4 access is = available, from at least one provider, with quality (connectivity, = reliability, support) approximately as good as IPv4, and at a reasonable = price.  In other words, you can't expect applications to rely on = native IPv6 until it's reliably available everywhere that they need to = use it.

"The = IETF sees no evolutionary future for the mechanism and it is not = recommended to include this mechanism in new = implementations."

6to4 never was intended to have an = "evolutionary future".  It was always intended as a near-term = solution to allow consenting hosts and networks to interchange IPv6 = traffic without prior support from the IPv4 networks that carry the = traffic.   It is premature to recommend that 6to4 be removed = from implementations.  We do not know how long it will take ISPs to = universally deploy IPv6.  Until they do, there will be a need for = individuals and enterprises using IPv6-based applications to be able to = exchange IPv6 traffic with hosts that only have IPv4 = connectivity.

WEG> As was discussed in the WGLC for this = document, enterprise applications will not realistically use 6to4 as a = means to reach IPv6 for business critical applications. It's simply not = reliable enough. It's also probably unlikely that those will go directly = to IPv6-only vs using dual-stack to ease that transition. Individuals = and Enterprises that use IPv6-only applications will need to make IPv6 = service a non-negotiable requirement for their ISPs, networks, and = devices rather than hoping that 6to4 = works.

With respect, the v6ops = working group is not in a good position to judge whether enterprise = applications will use 6to4.   Operators rarely have a good = understanding of what individual application users or developers need. =  They tend to focus mostly on the applications that generate the = most traffic,  or cause them particular amounts of trouble, or the = ones that their biggest customers need.  Problem is, those aren't = the only applications that are important.  Every application is = important to its users, no matter how much or little traffic (or = revenue) it generates.

6to4 is as reliable as = IPv4 is, if it isn't asked to cross a relay router.  And there are = valid reasons to use 6to4 even where IPv4 connectivity already = exists.

Even in cases where 6to4 traffic must = cross a relay router, sometimes it's the best solution available. =   

All of the = criticisms in section 3 have to do with the use of relays to exchange = traffic between 6to4 and native IPv6.   In many cases the = criticisms are overbroad.   Not all uses of 6to4 involve = relays.  For some of those that do need to use relays, it is not = necessarily the case that the relay is operated by an unknown = third-party.

WEG> Again, please substantiate this with = examples of implementations that are actively using non-relay 6to4. = Also, the number of applications of 6to4 that can be guaranteed to avoid = any unknown 3rd party relays is extremely limited due to the nature of = anycast and 6to4's asymmetric routing. The protocol action requested in = this draft in no way prevents one or more consenting networks from using = 6to4 and continuing to run relays for their local traffic indefinitely - = in fact, it even provides a reference to a document to show them how to = make it work as well as possible. It is simply saying that it's not a = good idea.

Application = implementations shouldn't care whether they're using relay 6to4, = non-relay 6to4, or 6to4 at all.  Application implementations should = at most care that they're using IPv6 rather than IPv4, and for some = applications even this is not = appropriate.

Application deployments = might well need to care how well their underlying networks work. =  Ideally, they shouldn't have to care, but that's the world we're = currently living in.

The requested protocol = action deprecates 6to4 and discourages its inclusion in future = implementations.  That's harmful to applications and users for whom = native IPv6 isn't available - which is to say, pretty much everyone at = the moment.  When native IPv6 becomes widely available, it will = then be appropriate to transition hosts and networks using 6to4 to = native IPv6.  But even then, there will probably still be a need = for host implementations 

The recommendations to treat 6to4 as a service of = last resort will do harm to users and applications using it. =   A better recommendation is for hosts to disable 6to4 by = default.

WEG> this seems to be to be splitting hairs. Please = explain the distinction you're making here. Disable by default means = never use. Use as last resort means use when no better IP connectivity = is available.

I was interpreting "treat = 6to4 as a service of last resort" as affecting the address and interface = selection algorithm.   If 6to4 is enabled on a host or network, = there are reasons to use 6to4 in preference to some other kinds of = connectivity.    The question of whether to enable 6to4 should = be separate from the question of "if 6to4 is enabled, what priority = should it have in address = selection?"

Keith

p.s. = I'd support the writing of an applicability statement for 6to4 that = recommends a narrowing of its applicability to specific use cases, and = I'm even willing to help write it.   But moving it to Historic is = going too far, and it sends the wrong message.   We need for 6to4 = in our toolbox to enable enterprises and applications developers to be = able to write and (tentatively, carefully) deploy applications that use = IPv6.   We can't afford to wait until all ISPs support native v6 = for people to start writing applications that use it. =  

= --Apple-Mail-11-587867425-- From brian.e.carpenter@gmail.com Tue Jun 7 08:45:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B891322800B; Tue, 7 Jun 2011 08:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.92 X-Spam-Level: X-Spam-Status: No, score=-102.92 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5skNXnit5OPk; Tue, 7 Jun 2011 08:45:23 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25A1E228006; Tue, 7 Jun 2011 08:45:23 -0700 (PDT) Received: by gyf3 with SMTP id 3so2752485gyf.31 for ; Tue, 07 Jun 2011 08:45:22 -0700 (PDT) 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=unmanW0s+Sfwp/bghJyiKm36AQSpOs42IoxY2ehs1Yo=; b=smrxQcGj6OFFq5UU8Er6micnHZ34VkUtQ6/XbIB53Yoj447j1EtzxtS4XTIVddAFY5 FCbJx7W3F5L3VRbpaaEBIPF+I5wXJmY240j9rRuea7D/+oXSCAB9XVqIRrMHorxtBdgC TBecpFY8NOxlwhDQBdm4hXNM+is2AUmIJs0lo= 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=YbZQdHZx6tnHcm48mJKA1OueD2+6uWpFVNq/gBVyPT3Don69xf9VBG5mHd6ycUk+9M zcWgurjqUchZpZrngHWiknnmVGzK1ZYhawY/6FtX2OWLrgMB1Mv8B3R+ww8QJsUtWylP HMIxPfN2/hd4FXP0X8iJH9pYgHPVTgJumF40I= Received: by 10.236.192.228 with SMTP id i64mr1135398yhn.111.1307461522680; Tue, 07 Jun 2011 08:45:22 -0700 (PDT) Received: from [10.71.0.232] ([12.68.183.2]) by mx.google.com with ESMTPS id w70sm206025yhl.45.2011.06.07.08.45.06 (version=SSLv3 cipher=OTHER); Tue, 07 Jun 2011 08:45:21 -0700 (PDT) Message-ID: <4DEE477C.9040709@gmail.com> Date: Wed, 08 Jun 2011 03:45:00 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> In-Reply-To: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, IETF-Announce Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4 to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:45:23 -0000 After a fair amount of thought, I have decided that I support this document without reservation. I support the recommendation that RFC 3056/3068 support should be off by default in CPEs; the reasons for this are clear enough in my companion draft. Specifically, I support the choice of "SHOULD NOT enable" (rather than MUST NOT) because it leaves open the option for a CPE or host vendor to enable RFC 3056/3068 by default if there is a sound reason to do so for a specific product. I support the recommendation to reclassify RFC 3056 as Historic, because its time is past. The reason for inventing 6to4 in the first place was for the benefit of customers whose ISPs could not deploy IPv6. There is now no reason or excuse for a consumer ISP to fail to deploy IPv6 for customers, so it is entirely reasonable to consider the technique as Historic. This has no impact on current successful use of 6to4 - the recommendation is to retain existing relays "until traffic diminishes" and to follow appropriate operational recommendations meanwhile. As my companion draft indicates, relays advertising the 2002::/16 prefix are needed as long as there is residual 6to4 traffic in the network. Regards Brian Carpenter (co-author of RFC 3056) From fred@cisco.com Tue Jun 7 09:41:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E296A11E817B for ; Tue, 7 Jun 2011 09:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.486 X-Spam-Level: X-Spam-Status: No, score=-110.486 tagged_above=-999 required=5 tests=[AWL=-0.487, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zfl6R+26Dt2l for ; Tue, 7 Jun 2011 09:41:27 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7292611E807A for ; Tue, 7 Jun 2011 09:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=752; q=dns/txt; s=iport; t=1307464887; x=1308674487; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=gWOt9DYmu9DIFQYr8zwoCcBgIDZJckDosWzDv/J9OHU=; b=QrpmxxQ7biB+gbNLXIeEsl0GOiFAXpqIkDuaZcbzJnlEpmkyXVmp1vY3 24g7KHq6Wf+xG0j9o/3ZoKhOITRFv2jePAjoLhQU60kFphA+18HhHIsvZ d7KWIE7HrLvXVsOYP2mbxa+knlrtiJJd60JCuMBkbHTp61rMGuGlvnvzG Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPpT7k2rRDoG/2dsb2JhbABSph93iHGjWZ4ghiEEhniKEoRMixk X-IronPort-AV: E=Sophos;i="4.65,333,1304294400"; d="scan'208";a="371959538" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 07 Jun 2011 16:41:27 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p57GfLJH022775; Tue, 7 Jun 2011 16:41:27 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 07 Jun 2011 09:41:27 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 07 Jun 2011 09:41:27 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4DED7A3D.1060008@viagenie.ca> Date: Tue, 7 Jun 2011 09:41:11 -0700 Message-Id: <8E93014B-E0BC-4001-95F4-D97917CFF2F6@cisco.com> References: <4DED7A3D.1060008@viagenie.ca> To: Marc Blanchet X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Call for agenda items X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:41:28 -0000 On Jun 6, 2011, at 6:09 PM, Marc Blanchet wrote: > to me, we should reserve significant time for many findings that would = follow June 8th. This is the best data points we could have for v6ops = charter. Therefore, I would suggest to chair to request as much slot = time as possible. Agreed that a post mortem (er, how do you say "after birth" or "after a = coming our party" in Latin?) is an important discussion to have. I have more or less done that. I routinely request a 2.5 hour slot and a = 2 hour slot, and last November requested two 2.5 hour slots (which we = didn't get, but we were placed on Friday afternoon and told that we had = explicit permission to run overtime). I have requested 4.5 hours this = time as well.= From bertietf@bwijnen.net Tue Jun 7 01:34:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9EF21F84BA for ; Tue, 7 Jun 2011 01:34:06 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8uj740wT5eD for ; Tue, 7 Jun 2011 01:34:05 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 3474E21F84B3 for ; Tue, 7 Jun 2011 01:34:05 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QTrje-00047C-U3 for v6ops@ietf.org; Tue, 07 Jun 2011 10:34:03 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest178.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QTrje-0001ee-R0 for v6ops@ietf.org; Tue, 07 Jun 2011 10:34:02 +0200 Message-ID: <4DEDE27A.8090800@bwijnen.net> Date: Tue, 07 Jun 2011 10:34:02 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd446e601e8f75df700d92baef0693f0c86 X-Mailman-Approved-At: Tue, 07 Jun 2011 09:54:44 -0700 Subject: [v6ops] v6day dashboard for World IPv6 day X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 08:34:06 -0000 FYI (I assume/hope this is relevant to this WG) The RIPE-NCC dashboard for world IPv6 day is now officially open at http://v6day.ripe.net/ It leads to loads of statistical and diagnostic information. We are still tweaking it a little and adding things. Bert From moore@network-heretics.com Tue Jun 7 11:20:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50B511E811F; Tue, 7 Jun 2011 11:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id desgCW1UYZfz; Tue, 7 Jun 2011 11:20:22 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id B0BE111E8092; Tue, 7 Jun 2011 11:20:22 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id BA96822433; Tue, 7 Jun 2011 14:20:21 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 07 Jun 2011 14:20:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=4+es+ZtqsvVOFTdqMrxSa9UGR6Q=; b=LVJQZhUQXQrvxUmiG7DGXWk1M6ig+IAnCtRtPGrTIT608XJHhTndVPGG7GtufhIdRdriSbQ98H0PdM8ZlgJQWekcMEraMwmx6fcvTSen2lgaIIMfK67wJntXMq6Jrwbdo1+yIJ+/VirK1N2Z0e+sxhFBPafpSa6CgN8DvJdUqds= X-Sasl-enc: j9Esr1JWmM3TzQ9499QdhTMjuAxJaIFJrzjbWv5i/wjM 1307470820 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 35A644047D6; Tue, 7 Jun 2011 14:20:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Tue, 7 Jun 2011 14:20:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> To: Ole Troan X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Working Group , ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 18:20:24 -0000 On Jun 7, 2011, at 4:48 AM, Ole Troan wrote: > I'm loathe to go through this discussion again. let me just respond to = some of the points you make, and then agree that we disagree. I'm also loathe to go through the discussion again. It shouldn't be = necessary. 6to4 has long been useful, and continues to be useful, for = some cases. It's appropriate to document problems with 6to4, perhaps = revise its applicability based on experience, and also to publish = recommendations for how to manage 6to4 relays, and to urge removal of = broken relays and/or filtering of their routing advertisements. But = deprecating it is entirely premature. (When I recently asked local ISPs = when they'll be offering IPv6 support, their answer was "what?". ) >> (It could be argued that reclassification of RFC 3068 (by itself) to = Historic is appropriate, but that would require a separate document and = last call.) >>=20 >> In addition, this document is misleading and perhaps even = vituperative. For instance: >>=20 >> "There would appear to be no evidence of any substantial deployment = of the variant of 6to4 described in [RFC3056]." >> This statement is blatantly false. 6to4 is supported by every major = desktop and server platfrom that is shipping today, and has been = supported for several years. >=20 > incorrect. there is no evidence that the _managed_ model of 6to4 = described in rfc3056 has any deployment. > that's the model where relay operators advertise what parts of the = 6to4 space they are routing. with BGP neighborships between managed and = participating relays. >=20 > _deployment_ not _support_. The recommendations of the proposal are overkill anyway. But assuming = there's some merit in writing an applicability statement for 6to4 (and I = think there might be), this text should be clearer and more balanced. And I'm not sure where you get the idea that RFC 3056 recommends that = relay operators advertise what parts of the 6to4 space they are routing. = 3056 doesn't say anything about BGP advertisements for IPv4, as 3056 = assumes there will be a manually configured relay router. As for = advertisement of IPv6 prefixes, the idea has always been that we didn't = want to incorporate the v4 routing table into v6, so 3056 specifically = says that the only prefix advertised in BGP should be 2002::/16. = (Obviously no such prefix should be advertised if the router isn't = willing and able to route to the entire 2002::/16 space, i.e. arbitrary = addresses on the public IPv4 network.) >> "The IETF sees no evolutionary future for the mechanism and it is not = recommended to include this mechanism in new implementations." >>=20 >> 6to4 never was intended to have an "evolutionary future". It was = always intended as a near-term solution to allow consenting hosts and = networks to interchange IPv6 traffic without prior support from the IPv4 = networks that carry the traffic. It is premature to recommend that = 6to4 be removed from implementations. We do not know how long it will = take ISPs to universally deploy IPv6. Until they do, there will be a = need for individuals and enterprises using IPv6-based applications to be = able to exchange IPv6 traffic with hosts that only have IPv4 = connectivity. =20 >>=20 >> All of the criticisms in section 3 have to do with the use of relays = to exchange traffic between 6to4 and native IPv6. In many cases the = criticisms are overbroad. Not all uses of 6to4 involve relays. For = some of those that do need to use relays, it is not necessarily the case = that the relay is operated by an unknown third-party. =20 >>=20 >> The fact that some firewalls block protocol 41 traffic causes = problems for many tunneling solutions, not just 6to4; yet this document = appears to recommend some tunneling solutions while trashing 6to4. >=20 > it is the unmanaged aspect of 6to4 deployment that exhibits the most = problems. a manually configured managed point to point tunnel may also = be blocked in a firewall, but then the operator will have to sort that = out. 6to4 has no operator. Indeed, that is one of its main virtues. 6to4 decouples application = deployment of v6 from network deployment of v6, and helps reduce the = "chicken or egg" problem. (At least, that's the intent. Reality is that 6to4 does have some = impact on the network, at least where relay routers that publicly = advertise prefixes through BGP are concerned. But 6to4 is useful - = admittedly in corner cases - even without relay routers.) > Teredo is similar in many aspects to 6to4, but there is little = evidence that it causes the same problems. largely because it is the = choice of last resort in implementations and it hasn't/can't be enabled = by default in CPEs. Bogus argument. Teredo has a different set of problems than 6to4 - = higher overhead, not as scalable, dependent on a single provider for = relays, not as widely deployed in hosts, etc. If you're seeing fewer = problems with Teredo, it's because it's not used as much as 6to4 is (in = part because it has more problems) - not because there are fewer = problems with it overall. In other words, you're blaming 6to4 for its = relative success. I think it's fair to say that 6to4 didn't anticipate the degree to which = relay routers and their BGP advertisements need to be monitored, and it = failed to make recommendations for this. But the same is true for IP. = When you get a BGP advertisement for a prefix that goes to a router that = drops the packets, you have to deal with it. When you get a BGP = advertisement for a 6to4 router that isn't working properly, you have to = deal with that too. The 6to4 relay problem may appear worse than the = normal bogus route advertisement case because all of the 6to4 related = bogus BGP advertisements are for the same two address prefixes (one IPv4 = and one IPv6). But from where I sit, I can't tell that it's a worse = problem overall. >> The recommendations to treat 6to4 as a service of last resort will do = harm to users and applications using it. A better recommendation is = for hosts to disable 6to4 by default. =20 >>=20 >> This document appears to make the mistake of assuming that the = purpose of applications using IPv6 is to interoperate with the existing = Internet. I have maintained for many years that it is new applications, = or existing applications that can't tolerate widespread deployment of = IPv4 NAT, that will drive use of IPv6. I therefore believe that it is = inappropriate to judge 6to4 merely by how well it works in scenarios = where it is being used to talk to applications that work well over IPv4 = NAT such as HTTP. The Internet is much more diverse than that, and = will become even more diverse as IPv6 enjoys wider deployment. >=20 > 6to4 does not work through IPv4 NATs. 6to4 can work through IPv4 NATs. Some NATs support 6to4 (and act as = NATs for v4, routers for v6). Other NATs can be manually configured to = pass protocol 41, and to have that traffic handled internally to the = interior network. Admittedly, 6to4 does not work though LSN. I see that as a bug in LSN, = if it doesn't provide a well-defined way for customers to get equivalent = functionality to 6to4. =20 >> It is also premature to remove references to 6to4 from RFC 5156bis, = for IANA to mark the prefix and DNS zones as deprecated. This will only = cause confusion and difficulty for legitimate continued uses of 6to4. >=20 > the purpose of the text in the document is to ensure that the = deprecated prefixes are not reused before 6to4 has been phased out. Just leave the allocation as-is until it really is time to deprecate = 6to4. Frankly I don't expect that to happen for another 5-10 years, but = I'd love to be surprised at the rapid acceleration in native IPv6 = deployment. Keith From moore@network-heretics.com Tue Jun 7 12:07:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FFA21F85EA for ; Tue, 7 Jun 2011 12:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuxiZEJRwRjW for ; Tue, 7 Jun 2011 12:07:48 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 827B921F85E7 for ; Tue, 7 Jun 2011 12:07:48 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 1D0A421057; Tue, 7 Jun 2011 15:07:48 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 07 Jun 2011 15:07:48 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=sWScbBZ9GT0UWoABW2T/8f8UO+8=; b=bCuyEVU4NvJ4mSaelpElYKq0yE5KJLDnlFvItKUNae+QEnVOFkfwwIblHmEuS4dYJrSQAEd/LGiD4Y6th7EjIoOhe2ZBGjPU+2vYhI5LmAyQW9gEAbtcaV9ytVNfdaNo+/tKSTngnj8+9jF75k36ZiX+fCXOjyEgZqcv4VX3rNk= X-Sasl-enc: 93uEAoeS2r3Pd4iT2s9dGkvOzxJrcd4FLUfvJqJ4nYGV 1307473667 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 148104013FA; Tue, 7 Jun 2011 15:07:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <1EF6364A-8B57-498E-B32C-2B588591CFB0@cisco.com> Date: Tue, 7 Jun 2011 15:07:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8BCDF4E7-E137-4F55-9C0B-93E0B3B7FDB7@network-heretics.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B6FD5@PRVPEXVS04.corp.twcable.com> <1EF6364A-8B57-498E-B32C-2B588591CFB0@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 19:07:49 -0000 On Jun 6, 2011, at 2:51 PM, Fred Baker wrote: > On Jun 6, 2011, at 10:35 AM, George, Wesley wrote: >=20 >> Did I miss the discussion where we decided to make this informational = instead of proposed standard? What was the rationale? >=20 > Requested by the AD. The argument for standards track was that it = addressed a standards track document. The IESG apparently opines that an = informational document will do the job and is their preference. FWIW, I agree that it's not appropriate to make a non-protocol document = into a Proposed Standard. On the other hand, I also believe that a = reclassification of a Proposed Standard to Historic should require an = IETF Consensus action, which is a higher bar than is required for = publication as Informational. There's no problem as long as all of the = normal process rules for IETF Consensus actions are followed. (this is of course a separate question from whether the proposal has = merit) Keith From tjc@ecs.soton.ac.uk Tue Jun 7 12:26:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B8011E81F7 for ; Tue, 7 Jun 2011 12:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuPd9gvHKXb9 for ; Tue, 7 Jun 2011 12:26:19 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id A49E011E810C for ; Tue, 7 Jun 2011 12:26:18 -0700 (PDT) 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 p57JQDnU018758 for ; Tue, 7 Jun 2011 20:26:13 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p57JQDnU018758 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1307474773; bh=ICi+zLf5jDUfxp3QPVyxa5yVk9s=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=p07RKypyNIX7MNhbXMHKjK6fXlsNXcvXErIquLH17vD/4auO8M04rjtckLIVVAXqV rp0MHKOeXiZoF13YUMxRu1U/+uYKR8F6YZK8ydXgfLw9DRd20PP02XcUWc926/AoA9 Fltl3++STzFLHaCd6WaYkE6IANRmLk2P49S0js58= 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 n56KQD0035649520VN ret-id none; Tue, 07 Jun 2011 20:26:13 +0100 Received: from [192.168.1.18] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p57JOqhp003463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 7 Jun 2011 20:24:53 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Tim Chown In-Reply-To: <20110607191840.16055.46020.idtracker@ietfa.amsl.com> Date: Tue, 7 Jun 2011 20:24:52 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20110607191840.16055.46020.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n56KQD003564952000; tid=n56KQD0035649520VN; 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: p57JQDnU018758 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] I-D Action: draft-chown-v6ops-call-to-arms-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 19:26:20 -0000 Hi, Just a relatively small tickle of the draft, with some comments and = links worked in, and Mat added as a co-author. I hope everyone taking part has a great day tomorrow, good luck :) Tim On 7 Jun 2011, at 20:18, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : World IPv6 Day Call to Arms > Author(s) : Tim Chown > Mat Ford > Stig Venaas > Filename : draft-chown-v6ops-call-to-arms-03.txt > Pages : 15 > Date : 2011-06-07 >=20 > The Internet Society (ISOC) has declared that June 8th 2011 will be > World IPv6 Day, on which some major organisations are going to make > their content available over IPv6. With the likes of Google and > Facebook providing IPv6 access to their production services and > domains, it is very likely we will see more IPv6 traffic flowing > across the Internet than has ever been seen before. With this in > mind, it seems timely to issue a call to arms for systems and = network > administrators to review their organisation's IPv6 capabilities = in > order to mitigate common causes of IPv6 connectivity problems in > advance of the day. The increased traffic on World IPv6 Day should > also create an excellent opportunity to observe the behaviour and > performance of IPv6; it is thus very desirable to have appropriate > measurement tools in place in advance. We discuss some appropriate > tools from the network and application perspective. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-chown-v6ops-call-to-arms-03.txt From mrex@sap.com Tue Jun 7 11:50:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A46411E808A; Tue, 7 Jun 2011 11:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.424 X-Spam-Level: X-Spam-Status: No, score=-8.424 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uabB+UQ56xy8; Tue, 7 Jun 2011 11:50:17 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF6A11E807A; Tue, 7 Jun 2011 11:50:17 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p57IoE4R017314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Jun 2011 20:50:14 +0200 (MEST) From: Martin Rex Message-Id: <201106071850.p57IoDhb011453@fs4113.wdf.sap.corp> To: wesley.george@twcable.com (George Wesley) Date: Tue, 7 Jun 2011 20:50:13 +0200 (MEST) In-Reply-To: <34E4F50CAFA10349A41E0756550084FB067B72F8@PRVPEXVS04.corp.twcable.com> from "George, Wesley" at Jun 7, 11 08:56:27 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Mailman-Approved-At: Tue, 07 Jun 2011 12:34:31 -0700 Cc: v6ops@ietf.org, ietf@ietf.org, trejrco@gmail.com Subject: Re: [v6ops] Last Call: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 18:50:19 -0000 George, Wesley wrote: > > > It's time to remove the stabilisers on the IPv6 bicycle. > > This takes nothing away. It's not as if the day that this draft gets > published as an RFC, 6to4 stops working. In my personal perception, the "historic" status used to be a technical characterization to indicate that (1) a protocol or technology has been fully replaced by some newer protocol and there is no reason to continue using the original technology anymore because the successor can be used in each of the original usage scenarios today (2) the protocol/technology has been largely put out of use, and its active use has dropped to marginal levels (like less than 1% of the original active use) Personally, I have never conciously used anything related to IPv6 so far, so for me it is difficult to comment, but what has been said looks to me that neither (1) nor (2) apply to 6to4. The user base seems to have always been small, and most of the users of 6to4 simply did _not_ have an alternative -- and its current users still do _not_ have an alternative today. Classification of 6to4 as historic is appropriate use of the IETF process, because it would be a political, but not an accurate technical statement. -Martin From iesg-secretary@ietf.org Tue Jun 7 12:41:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E97411E823F; Tue, 7 Jun 2011 12:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYYSthtMTeCS; Tue, 7 Jun 2011 12:41:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC13511E81E3; Tue, 7 Jun 2011 12:41:01 -0700 (PDT) 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.55 Message-ID: <20110607194101.5072.76302.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2011 12:41:01 -0700 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (IPv6 Multihoming without Network Address Translation) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 19:41:02 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'IPv6 Multihoming without Network Address Translation' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements, because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution and optionally DNS resolution. For IPv6 hosts one approach could be the use of IPv6 NAT. However, NAT should be avoided, if at all possible, to permit transparent host-to- host connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6 allocation criteria. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/ No IPR declarations have been submitted directly on this I-D. From wesley.george@twcable.com Tue Jun 7 14:28:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C7911E8147; Tue, 7 Jun 2011 14:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.237 X-Spam-Level: X-Spam-Status: No, score=0.237 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gONreNjtj3O; Tue, 7 Jun 2011 14:28:00 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id ED5F711E80C2; Tue, 7 Jun 2011 14:27:59 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,334,1304308800"; d="scan'208";a="235478474" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 07 Jun 2011 17:35:02 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 7 Jun 2011 17:27:59 -0400 From: "George, Wesley" To: Keith Moore Date: Tue, 7 Jun 2011 17:27:57 -0400 Thread-Topic: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC Thread-Index: AcwlJoh/Y7coZ0uwSNq4LC+KQclORwAA32nA Message-ID: <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> In-Reply-To: <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "ietf@ietf.org" Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 21:28:01 -0000 From: Keith Moore [mailto:moore@network-heretics.com] Sent: Tuesday, June 07, 2011 11:21 AM To: George, Wesley Cc: ietf@ietf.org; v6ops@ietf.org Subject: Re: [v6ops] Last Call: = (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Histo= ric status) to Informational RFC WEG> Please substantiate these claims. What are the use cases, and why are = there no other solutions for those specific use cases? What is considered "= widespread ISP support for native IPV6"? KM>The best current use cases for 6to4 that I'm aware of are: KM>- Applications developers want to be forward thinking and develop IPv6 a= pps, but cannot get native IPv6 access. 6to4 allows them to develop those = apps and test or use them in useful situations (i.e. outside of a lab) with= out having to configure a separate tunnel to every host involved. Note th= at 6to4 is useful in this way even if all of the addresses used are 6to4 ad= dresses, and the traffic therefore does not cross any relays between 6to4 a= nd native IPv6. WEG> Exactly my point. this is a valid use case, but 6to4 is by no means th= e only way to solve it. Application developers are welcome to set up an IPv= 6 network to test their apps against. That doesn't require IPv6 connectivit= y to the outside world. If you have more than one of any modern computer on= your LAN and you turn the right knobs, they can all talk to each other via= IPv6 independent of any external IPv6 connectivity. You seem to want to dr= aw this distinction between IPv6 between two hosts using 6to4 since that "w= orks" and using 6to4 as a means to connect to the IPv6 Internet via relays,= but then you conflate them by repeatedly complaining about lack of IPv6 se= rvice available from most ISPs and presenting 6to4 as a solution. Further, I don't buy the "separate tunnel to every host..." thing. Tunneled= IPv6 connectivity is widely available. All any developer needs to do if th= ey can't get Native IPv6 and a tunneled application is deemed good enough f= or their testing purposes is connect both ends of their testing environment= to their choice of tunnel broker, and through the magic of the internet, t= hey're all connected to one another. KM> - Enterprises have applications that need to be able to communicate wit= h large numbers of hosts spread over a diverse area. IPv6 is clearly the w= ay that they want to go, but it's not widely available at present. 6to4 pr= ovides them with a means of routing traffic to their hosts in the interim u= ntil widespread support for IPv6 exists. WEG> So do IPv6IP or GRE tunnels. Been using one at home for 3+ years now. = And honestly, if this type of application is going to be enterprise-class, = it needs to be in conjunction with ISP deployment of IPv6, not in spite of = it. KM> - Users (including enterprise users) who have small networks with IPv4 = access (generally behind v4 NATs) can use 6to4 to allow them to remotely ac= cess individual hosts on those networks. This can be done either with a NA= T that also acts as a v6 router and supports 6to4 as an external connection= , or by configuring the NAT to pass protocol 41 to a IPv6 router for the ne= twork, internal to the v4 NAT. WEG> Until CGN becomes common, in which case 6to4 doesn't work again. Also,= that same NAT + v6 router combination could just as easily manage a static= tunnel. KM>Widespread IPv6 support for native IPv6 would be when native IPv6 is ava= ilable everywhere that IPv4 access is available, from at least one provider= , with quality (connectivity, reliability, support) approximately as good a= s IPv4, and at a reasonable price. In other words, you can't expect applic= ations to rely on native IPv6 until it's reliably available everywhere that= they need to use it. WEG> So Widespread IPv6 has to have reliability and support equivalent to I= Pv4, yet you're saying that you can expect applications to rely on 6to4 in = the meantime despite evidence that it's unreliable, and the virtual guarant= ee that it won't be supported by the upstream ISP? And you and I disagree about the definition of widespread. I do not think t= hat widespread means "every small ISP in every corner of the world supports= it ubiquitously and at every price point." I think it means "it's availabl= e for a majority (>50%) of Internet service customers." WEG> As was discussed in the WGLC for this document, enterprise application= s will not realistically use 6to4 as a means to reach IPv6 for business cri= tical applications. It's simply not reliable enough. It's also probably unl= ikely that those will go directly to IPv6-only vs using dual-stack to ease = that transition. Individuals and Enterprises that use IPv6-only application= s will need to make IPv6 service a non-negotiable requirement for their ISP= s, networks, and devices rather than hoping that 6to4 works. KM> With respect, the v6ops working group is not in a good position to judg= e whether enterprise applications will use 6to4. Operators rarely have a = good understanding of what individual application users or developers need.= They tend to focus mostly on the applications that generate the most traf= fic, or cause them particular amounts of trouble, or the ones that their b= iggest customers need. Problem is, those aren't the only applications that= are important. Every application is important to its users, no matter how= much or little traffic (or revenue) it generates. WEG> I'm not going to touch the "operators don't know what they're talking = about" part of your comment, except to note that it's a gross generalizatio= n that won't help your argument, and wonder how you are uniquely qualified = to know better than the rest of us... I am simply saying that I do not for = a second believe that those same applications that are so important to that= user community are at the same time unimportant enough that they're the sa= crificial lamb that has to go IPv6-only when the majority of that user comm= unity, no matter how small, doesn't have native IPv6 access yet. This is th= e essence of the IPv6 content vs access chicken/egg problem, and 6to4 absol= utely will not break the impasse. 6to4 breakage is the most common thing th= at content providers cite as reasons why they don't just go dual-stack. Why= would an enterprise application be any different? KM> 6to4 is as reliable as IPv4 is, if it isn't asked to cross a relay rout= er. WEG> perhaps (with the exception of MTU issues that plague any tunneled pro= tocol), but you continue to not provide any examples of this being used any= where, in the face of significant evidence that 6to4 is horribly unreliable= *with* a relay. So this gets filed in the same place as my 100% secure fil= e server which happens to be unplugged from power and network and encased i= n 10ft of concrete. Theoretically perfect, but otherwise practically useles= s. KM> And there are valid reasons to use 6to4 even where IPv4 connectivity al= ready exists. WEG> One would hope you wouldn't be trying to use 6to4 where IPv4 connectiv= ity *doesn't* exist. KM>Even in cases where 6to4 traffic must cross a relay router, sometimes it= 's the best solution available. WEG> Perhaps, but again, we're talking about such a small percentage of the= time that the cure ends up being worse than the disease. I love orphans an= d lost causes as much as the next guy, but really... KM>All of the criticisms in section 3 have to do with the use of relays to = exchange traffic between 6to4 and native IPv6. In many cases the criticis= ms are overbroad. Not all uses of 6to4 involve relays. For some of those= that do need to use relays, it is not necessarily the case that the relay = is operated by an unknown third-party. WEG> Again, please substantiate this with examples of implementations that = are actively using non-relay 6to4. Also, the number of applications of 6to4= that can be guaranteed to avoid any unknown 3rd party relays is extremely = limited due to the nature of anycast and 6to4's asymmetric routing. The pro= tocol action requested in this draft in no way prevents one or more consent= ing networks from using 6to4 and continuing to run relays for their local t= raffic indefinitely - in fact, it even provides a reference to a document t= o show them how to make it work as well as possible. It is simply saying th= at it's not a good idea. KM> Application implementations shouldn't care whether they're using relay = 6to4, non-relay 6to4, or 6to4 at all. Application implementations should a= t most care that they're using IPv6 rather than IPv4, and for some applicat= ions even this is not appropriate. Application deployments might well need to care how well their underlying n= etworks work. Ideally, they shouldn't have to care, but that's the world w= e're currently living in. WEG> First, you're hair-splitting between implementation and deployment. Ho= wever you want to call it, I'm referring to "situations" where 6to4 is in u= se without relays and is performing reliably on a business-critical use to = justify your assertion that we shouldn't toss out this part of 6to4 along w= ith the anycast/relay part because it's still so useful. WEG> I agree that properly written applications are IP version-agnostic. Th= ere is only a question of whether they work through one or more layers of I= Pv4 NAT, or they don't. If they don't, then the solution is IPv6. If IPv6 i= sn't available, you have many major content providers saying that they abso= lutely don't see 6to4 as an acceptable substitute, meaning that your suppos= ed application of 6to4 as a fix for this problem is so niche as to be harmf= ul rather than helpful. Why are we having a World IPv6 Day? In part to shak= e loose the broken 6to4 users that may not even know that 6to4 is enabled/b= roken so that content providers can be more confident that they can dual-st= ack their websites without risk of significant user impact due to breakage. KM> The requested protocol action deprecates 6to4 and discourages its inclu= sion in future implementations. That's harmful to applications and users f= or whom native IPv6 isn't available - which is to say, pretty much everyone= at the moment. When native IPv6 becomes widely available, it will then be= appropriate to transition hosts and networks using 6to4 to native IPv6. B= ut even then, there will probably still be a need for host implementations WEG> Well, it'd be more harmful if there weren't alternatives. Also, assumi= ng that the protocol is declared historical, we're now in a footrace betwee= n ISPs deploying IPv6 and equipment vendors removing support for 6to4 (or r= olling out new products that don't support it in the first place). I think = you're oversensationalizing both the impact of this draft and the lack of I= Pv6, given that nearly all major ISPs in the commercial space are currently= offering or have a timeline to offer Native IPv6, and a large amount of th= e ISPs in the residential space have a timeline for deployment, many have a= lready started trials. Finally, we're having problems with equipment that doesn't support IPv6 at = all. 6to4 is not high on the priority list to implement compared with a fun= ctional IPv6 stack, meaning that on new gear, it likely won't get implement= ed until it's no longer necessary. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From moore@network-heretics.com Tue Jun 7 15:47:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92AAF11E8164; Tue, 7 Jun 2011 15:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=-1.425, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyfQFubrFV0U; Tue, 7 Jun 2011 15:47:55 -0700 (PDT) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id AC97F11E8147; Tue, 7 Jun 2011 15:47:54 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id A4A602180D; Tue, 7 Jun 2011 18:47:52 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 07 Jun 2011 18:47:52 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=AvcFsQEIYTvtiOXvUyZMPUB4EBU=; b=WHbz8rQ+7q/dn1++t4ULD7ZgB/Ibb2mhoFFRw2+JGFp3+km7sr7J/vFeNee51FgRoU+PTAkJx5lwfSAz/C7RVVXD5eVrvLPFOUbF389lCeoNkMCE2TC4nOnQabSlv7XT1zh2E2PlXOxmFv+OqSKNpQ2ayMGy+etD1qxQ0gu8hS8= X-Sasl-enc: e21TgKuK6l1kfvpjHTpeV5FqP2Mgn0J2hQQLLlXBL2Es 1307486868 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 0FDF044320A; Tue, 7 Jun 2011 18:47:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-18-614669036 From: Keith Moore In-Reply-To: <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> Date: Tue, 7 Jun 2011 18:47:47 -0400 Message-Id: <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> To: "George, Wesley" X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , "ietf@ietf.org" Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 22:47:57 -0000 --Apple-Mail-18-614669036 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 7, 2011, at 5:27 PM, George, Wesley wrote: >=20 > From: Keith Moore [mailto:moore@network-heretics.com] > Sent: Tuesday, June 07, 2011 11:21 AM > To: George, Wesley > Cc: ietf@ietf.org; v6ops@ietf.org > Subject: Re: [v6ops] Last Call: = (Request to move Connection = of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to = Informational RFC >=20 > WEG> Please substantiate these claims. What are the use cases, and why = are there no other solutions for those specific use cases? What is = considered "widespread ISP support for native IPV6"? >=20 > KM>The best current use cases for 6to4 that I'm aware of are: >=20 > KM>- Applications developers want to be forward thinking and develop = IPv6 apps, but cannot get native IPv6 access. 6to4 allows them to = develop those apps and test or use them in useful situations (i.e. = outside of a lab) without having to configure a separate tunnel to every = host involved. Note that 6to4 is useful in this way even if all of the = addresses used are 6to4 addresses, and the traffic therefore does not = cross any relays between 6to4 and native IPv6. >=20 > WEG> Exactly my point. this is a valid use case, but 6to4 is by no = means the only way to solve it. Application developers are welcome to = set up an IPv6 network to test their apps against. Why are you trying to make life harder for developers of IPv6 = applications? There's no reason at all that an application developer = should have to set up a special-purpose network just to test an IPv6 = application.=20 > That doesn't require IPv6 connectivity to the outside world. Realistic testing of applications needs to be done on real networks, or = a least an approximation to real networks. Testing IPv6 using 6to4 over = public IPv4 obviously isn't perfect, but it's a hell of a lot more = realistic than setting up a lab network and confining one's testing to = that. > If you have more than one of any modern computer on your LAN and you = turn the right knobs, they can all talk to each other via IPv6 = independent of any external IPv6 connectivity. You seem to want to draw = this distinction between IPv6 between two hosts using 6to4 since that = "works" and using 6to4 as a means to connect to the IPv6 Internet via = relays, but then you conflate them by repeatedly complaining about lack = of IPv6 service available from most ISPs and presenting 6to4 as a = solution. I've been using 6to4 on a regular, often daily, basis since the late = 1990s. 6to4 has allowed me to develop IPv6 applications and test them = on real networks, and deploy them in limited circumstances. 6to4 has = also allowed me to remotely access computers on my SOHO networks, using = any application protocol that I chose to do so, with out-of-the-box = hardware and software, without any application-specific proxies, and = generally without any application-specific configuration. None of these = scenarios required a relay router. All of them were, and continue to = be, useful. Yes, I've experienced on many occasions that using 6to4 to access = dual-stack web servers doesn't always work so well. Sometimes it picks = a suboptimal path because the relay router isn't convenient. Sometimes = the v6 path doesn't work at all and the application has to time out and = retry using v4. But this never really bothered me much, because my = purpose in using 6to4 wasn't to try to access services that I could get = to via IPv4 anyway. And neither, I suggest, is that a reasonable metric = for evaluating 6to4 or any other IPv6 transition mechanism. The metric = for evaluating an IPv6 transition mechanism should be based on its = effectiveness in accessing services that are IPv6 only. =20 And sure, 6to4 is a sort of last resort for those services, except maybe = for the other transition mechanisms that are worse: Teredo is often = worse, configured tunnels are often worse, for all of the obvious = reasons. If your ISP offers you native IPv6 access you should probably = use that instead, even if internally they use 6rd or some other = tunneling scheme. There's definitely benefit to having professional = management and support (such as it is) for your IPv6 connectivity. =20 Yet, time and time again the argument gets made that 6to4 gets in the = way of trying to access such services. 6to4 by itself is not the = problem. The problem is address selection rules that favor v6 over v4. = If the service is supported under v4, if it works fine through any NATs = in the signal path, the application should probably use v4 to talk to = that service. And if the service is v6-only, and 6to4 is the best way = of getting there that's available, you might as well try to use it. > Further, I don't buy the "separate tunnel to every host..." thing. = Tunneled IPv6 connectivity is widely available. All any developer needs = to do if they can't get Native IPv6 and a tunneled application is deemed = good enough for their testing purposes is connect both ends of their = testing environment to their choice of tunnel broker, and through the = magic of the internet, they're all connected to one another. You seem to have this fixed idea of how applications should be tested = and used, that is inconsistent with my experience. "Both" ends of their = testing environment? What gives you the idea that there are only two = ends? Distributed development projects are quite commonplace, and can = involve hundreds or even thousands of people, each at different sites. = Nor is there necessarily some sort of central network that everything = connects to. Nor should there be.=20 > KM> - Enterprises have applications that need to be able to = communicate with large numbers of hosts spread over a diverse area. = IPv6 is clearly the way that they want to go, but it's not widely = available at present. 6to4 provides them with a means of routing = traffic to their hosts in the interim until widespread support for IPv6 = exists. >=20 > WEG> So do IPv6IP or GRE tunnels. Been using one at home for 3+ years = now. And honestly, if this type of application is going to be = enterprise-class, it needs to be in conjunction with ISP deployment of = IPv6, not in spite of it. What you're saying is that applications developers shouldn't bother with = actually trying to use IPv6 until the ISPs get their act together and = deploy it. Well guess what? The ISPs have let us down. We've been = waiting for 15 years for the ISPs to roll out IPv6, and for most of = those 15 years they were all telling us that there were no applications = for it. Now the ISPs are scrambling to get IPv6 into their networks, = and they want to sabotage the IPv6 mechanisms that we have in place even = before they are actually offering product. > KM> - Users (including enterprise users) who have small networks with = IPv4 access (generally behind v4 NATs) can use 6to4 to allow them to = remotely access individual hosts on those networks. This can be done = either with a NAT that also acts as a v6 router and supports 6to4 as an = external connection, or by configuring the NAT to pass protocol 41 to a = IPv6 router for the network, internal to the v4 NAT. >=20 > WEG> Until CGN becomes common, in which case 6to4 doesn't work again. = Also, that same NAT + v6 router combination could just as easily manage = a static tunnel. You're missing something. I can connect directly from my mobile laptop = to a machine in my home network using 6to4. I didn't have to set up any = static tunnel for either one. Sure, I could do that, I could get = tunnels from HE or some other source and route through them. Why should = I bother? Why do I want to make my IPv6 traffic take any longer a route = than necessary? You've argued against 6to4 with relay routers because = it's routing can be suboptimal, but the same is true of any other = tunneling scheme. > KM>Widespread IPv6 support for native IPv6 would be when native IPv6 = is available everywhere that IPv4 access is available, from at least one = provider, with quality (connectivity, reliability, support) = approximately as good as IPv4, and at a reasonable price. In other = words, you can't expect applications to rely on native IPv6 until it's = reliably available everywhere that they need to use it. >=20 > WEG> So Widespread IPv6 has to have reliability and support equivalent = to IPv4, yet you're saying that you can expect applications to rely on = 6to4 in the meantime despite evidence that it's unreliable, and the = virtual guarantee that it won't be supported by the upstream ISP? There's no such virtual guarantee. =20 > And you and I disagree about the definition of widespread. I do not = think that widespread means "every small ISP in every corner of the = world supports it ubiquitously and at every price point." I think it = means "it's available for a majority (>50%) of Internet service = customers." We can disagree about the meaning of the word "widespread", but the = practical fact is that you can't expect people to give up something that = works for them until you can provide them something that works better = for them. "Available to 50% of Internet service customers" is = equivalent to a very small percent probability of native connectivity = being able to replace 6to4 connectivity in a scenario where 6to4 is = currently working. And the more hosts involved, the smaller that = probability is.=20 > WEG> As was discussed in the WGLC for this document, enterprise = applications will not realistically use 6to4 as a means to reach IPv6 = for business critical applications. It's simply not reliable enough. = It's also probably unlikely that those will go directly to IPv6-only vs = using dual-stack to ease that transition. Individuals and Enterprises = that use IPv6-only applications will need to make IPv6 service a = non-negotiable requirement for their ISPs, networks, and devices rather = than hoping that 6to4 works. >=20 > KM> With respect, the v6ops working group is not in a good position to = judge whether enterprise applications will use 6to4. Operators rarely = have a good understanding of what individual application users or = developers need. They tend to focus mostly on the applications that = generate the most traffic, or cause them particular amounts of trouble, = or the ones that their biggest customers need. Problem is, those aren't = the only applications that are important. Every application is = important to its users, no matter how much or little traffic (or = revenue) it generates. >=20 > WEG> I'm not going to touch the "operators don't know what they're = talking about" part of your comment, except to note that it's a gross = generalization that won't help your argument, and wonder how you are = uniquely qualified to know better than the rest of us... Seems to me it's the v6ops people who are making the gross = generalizations. I'm mostly pointing out exceptions to those gross = generalizations that have been made here and in v6ops. =20 > I am simply saying that I do not for a second believe that those same = applications that are so important to that user community are at the = same time unimportant enough that they're the sacrificial lamb that has = to go IPv6-only when the majority of that user community, no matter how = small, doesn't have native IPv6 access yet. You have absolutely no idea which applications will be important to the = user community tomorrow. Who knows what will be the next netflix, = twitter, facebook, youtube, ... ? The Internet is successful not = because it supports some small number of apps that operators think are a = good idea; it's successful because it (at least as originally = architected) can support a wide range of apps without operators having = to bless them.=20 > This is the essence of the IPv6 content vs access chicken/egg problem, = and 6to4 absolutely will not break the impasse. 6to4 breakage is the = most common thing that content providers cite as reasons why they don't = just go dual-stack. Why would an enterprise application be any = different? It doesn't really matter much whether "content-providers" (as in web = site providers) go "dual stack" now. Sure, they need to be gearing up = for it, making sure that they understand it, making sure that their = networks support it. (Or maybe they'll just install v6-to-v4 proxies at = their borders so that they can keep providing good customer service in = the face of LSN-induced brain damage on the public v4 network.) But = assuming their applications work through LSN, they're going to keep = supporting v4 for a long time anyway, because that's the established = base of interoperability for their products and services. Existing = "content providers" are not going to drive adoption of IPv6. They're = going to follow it. Web and email will be the last applications to = migrate. New content might appear on v6, and that might drive adoption. = But to the extent that it drives adoption, it probably won't be from = the currently established players that already have plenty of v4 = addresses and infrastructure. It will be from new things that take = advantage of the niches created by IPv6 that didn't exist before. > KM> 6to4 is as reliable as IPv4 is, if it isn't asked to cross a relay = router. > WEG> perhaps (with the exception of MTU issues that plague any = tunneled protocol), but you continue to not provide any examples of this = being used anywhere, in the face of significant evidence that 6to4 is = horribly unreliable *with* a relay. So this gets filed in the same place = as my 100% secure file server which happens to be unplugged from power = and network and encased in 10ft of concrete. Theoretically perfect, but = otherwise practically useless. What is "anywhere" to you? You seem to have a content-centric view of = the Internet. I do not. Meanwhile, you persist in saying that = something that I've used regularly for more than 10 years, to do useful = work, isn't being used anywhere. I keep seeing figures that 6to4 = comprises 40-some-odd percent of IPv6 traffic, while native IPv6 is = around 10 percent. By your logic, native v6 should be deprecated = because it doesn't work reliably and it's not being used anywhere. > KM> And there are valid reasons to use 6to4 even where IPv4 = connectivity already exists. > WEG> One would hope you wouldn't be trying to use 6to4 where IPv4 = connectivity *doesn't* exist. Right, but the point is that there are valid use cases for 6to4 even = where you have IPv4 connectivity for part or even all of the network = that you're using. > KM>Even in cases where 6to4 traffic must cross a relay router, = sometimes it's the best solution available. > WEG> Perhaps, but again, we're talking about such a small percentage = of the time that the cure ends up being worse than the disease. I love = orphans and lost causes as much as the next guy, but really... The disease is the current IPv4 network with NATs and LSNs and a paucity = of address space. 6to4 is like a drug that can let some valuable v6 = applications grow (even if a bit stunted) and survive until there's once = again a network that will support them. Sure, there are some side = effects and contraindications. But it's useful when used with awareness = of its limitations. You're arguing that it should be discouraged = because it causes some problems. Indeed it does. But LSN also causes = problems, and is a bigger dead-end than 6to4, and it's full steam ahead = with that. At least 6to4 is designed to ease transition to a saner = world, which is a lot more than I can say for LSN. > KM>All of the criticisms in section 3 have to do with the use of = relays to exchange traffic between 6to4 and native IPv6. In many cases = the criticisms are overbroad. Not all uses of 6to4 involve relays. = For some of those that do need to use relays, it is not necessarily the = case that the relay is operated by an unknown third-party. >=20 > WEG> Again, please substantiate this with examples of implementations = that are actively using non-relay 6to4. Also, the number of = applications of 6to4 that can be guaranteed to avoid any unknown 3rd = party relays is extremely limited due to the nature of anycast and = 6to4's asymmetric routing. The protocol action requested in this draft = in no way prevents one or more consenting networks from using 6to4 and = continuing to run relays for their local traffic indefinitely - in fact, = it even provides a reference to a document to show them how to make it = work as well as possible. It is simply saying that it's not a good idea. >=20 > KM> Application implementations shouldn't care whether they're using = relay 6to4, non-relay 6to4, or 6to4 at all. Application implementations = should at most care that they're using IPv6 rather than IPv4, and for = some applications even this is not appropriate. > Application deployments might well need to care how well their = underlying networks work. Ideally, they shouldn't have to care, but = that's the world we're currently living in. >=20 > WEG> First, you're hair-splitting between implementation and = deployment. However you want to call it, I'm referring to "situations" = where 6to4 is in use without relays and is performing reliably on a = business-critical use to justify your assertion that we shouldn't toss = out this part of 6to4 along with the anycast/relay part because it's = still so useful. You're attacking 6to4 on the basis of irrelevancies. As for = business-critical, that's up to the business using it to determine = whether it works well enough for their purposes. There are a lot of = technically dubious practices used in business critical applications and = networks. > WEG> I agree that properly written applications are IP = version-agnostic. There is only a question of whether they work through = one or more layers of IPv4 NAT, or they don't. If they don't, then the = solution is IPv6. If IPv6 isn't available, you have many major content = providers saying that they absolutely don't see 6to4 as an acceptable = substitute, meaning that your supposed application of 6to4 as a fix for = this problem is so niche as to be harmful rather than helpful. The notion that "properly written applications are IP version-agnostice" = is naive and overbroad. IPv6 works differently enough from IPv4 that = many applications cannot treat them the same. Simple client-server = apps, perhaps, can ignore their differences, but that's just a corner = case. =20 I have no doubt that many of those "major content providers" are correct = when they don't see 6to4 as an acceptable substitute for them. But the = Internet doesn't exist just to support "major content providers". So = stop trying to sabotage something that works well enough for other = users. > Why are we having a World IPv6 Day? In part to shake loose the broken = 6to4 users that may not even know that 6to4 is enabled/broken so that = content providers can be more confident that they can dual-stack their = websites without risk of significant user impact due to breakage. I'm looking forward to World IPv6 Day, and what will be learned from it. = But again, how well 6to4 works with "major content providers" is = irrelevant. > KM> The requested protocol action deprecates 6to4 and discourages its = inclusion in future implementations. That's harmful to applications and = users for whom native IPv6 isn't available - which is to say, pretty = much everyone at the moment. When native IPv6 becomes widely available, = it will then be appropriate to transition hosts and networks using 6to4 = to native IPv6. But even then, there will probably still be a need for = host implementations >=20 > WEG> Well, it'd be more harmful if there weren't alternatives. There aren't any good ones. Teredo and configured tunnels are worse in = many ways; though they each have their use cases. =20 > Also, assuming that the protocol is declared historical, we're now in = a footrace between ISPs deploying IPv6 and equipment vendors removing = support for 6to4 (or rolling out new products that don't support it in = the first place). I think you're oversensationalizing both the impact of = this draft and the lack of IPv6, given that nearly all major ISPs in the = commercial space are currently offering or have a timeline to offer = Native IPv6, and a large amount of the ISPs in the residential space = have a timeline for deployment, many have already started trials. > Finally, we're having problems with equipment that doesn't support = IPv6 at all. 6to4 is not high on the priority list to implement compared = with a functional IPv6 stack, meaning that on new gear, it likely won't = get implemented until it's no longer necessary. Gear that doesn't support IPv6 by now is pretty odd gear. But I'm = not going to tell you not to use it. I'm just saying, if you want odd = gear to work for you in your own specific use cases, don't try to = sabotage other odd things that work for other people in their specific = use cases. Keith --Apple-Mail-18-614669036 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

From: Keith Moore = [mailto:moore@network-heretics.com]
Sent: Tuesday, June 07, 2011 = 11:21 AM
To: George, Wesley
Cc: ietf@ietf.org; v6ops@ietf.org
Subject: Re: = [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt> = (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to = Historic status) to Informational RFC

WEG> Please substantiate = these claims. What are the use cases, and why are there no other = solutions for those specific use cases? What is considered "widespread = ISP support for native IPV6"?

KM>The best current use cases = for 6to4 that I'm aware of are:

KM>- Applications developers = want to be forward thinking and develop IPv6 apps, but cannot get native = IPv6 access.  6to4 allows them to develop those apps and test or = use them in useful situations (i.e. outside of a lab) without having to = configure a separate tunnel to every host involved.   Note = that 6to4 is useful in this way even if all of the addresses used are = 6to4 addresses, and the traffic therefore does not cross any relays = between 6to4 and native IPv6.

WEG> Exactly my point. this is a = valid use case, but 6to4 is by no means the only way to solve it. = Application developers are welcome to set up an IPv6 network to test = their apps against.

Why are you trying = to make life harder for developers of IPv6 applications?  There's = no reason at all that an application developer should have to set up a = special-purpose network just to test an IPv6 = application. 

That = doesn't require IPv6 connectivity to the outside world. =

Realistic testing of applications = needs to be done on real networks, or a least an approximation to real = networks.  Testing IPv6 using 6to4 over public IPv4 obviously isn't = perfect, but it's a hell of a lot more realistic than setting up a lab = network and confining one's testing to = that.

If you = have more than one of any modern computer on your LAN and you turn the = right knobs, they can all talk to each other via IPv6 independent of any = external IPv6 connectivity. You seem to want to draw this distinction = between IPv6 between two hosts using 6to4 since that "works" and using = 6to4 as a means to connect to the IPv6 Internet via relays, but then you = conflate them by repeatedly complaining about lack of IPv6 service = available from most ISPs and presenting 6to4 as a = solution.

I've been using 6to4 = on a regular, often daily, basis since the late 1990s.   6to4 has = allowed me to develop IPv6 applications and test them on real networks, = and deploy them in limited circumstances.  6to4 has also allowed me = to remotely access computers on my SOHO networks, using any application = protocol that I chose to do so, with out-of-the-box hardware and = software, without any application-specific proxies, and generally = without any application-specific configuration.  None of these = scenarios required a relay router.  All of them were, and continue = to be, useful.

Yes, I've experienced on many = occasions that using 6to4 to access dual-stack web servers doesn't = always work so well.  Sometimes it picks a suboptimal path because = the relay router isn't convenient.  Sometimes the v6 path doesn't = work at all and the application has to time out and retry using v4. =   But this never really bothered me much, because my purpose in = using 6to4 wasn't to try to access services that I could get to via IPv4 = anyway.  And neither, I suggest, is that a reasonable metric = for evaluating 6to4 or any other IPv6 transition mechanism.   The = metric for evaluating an IPv6 transition mechanism should be based on = its effectiveness in accessing services that are IPv6 only. =   

And sure, 6to4 is a sort of last = resort for those services, except maybe for the other transition = mechanisms that are worse: Teredo is often worse, configured tunnels are = often worse, for all of the obvious reasons.  If your ISP offers = you native IPv6 access you should probably use that instead, even if = internally they use 6rd or some other tunneling scheme.  There's = definitely benefit to having professional management and support (such = as it is) for your IPv6 connectivity. =  

Yet, time and time again the argument = gets made that 6to4 gets in the way of trying to access such services. =  6to4 by itself is not the problem.  The problem is address = selection rules that favor v6 over v4.  If the service is supported = under v4, if it works fine through any NATs in the signal path, the = application should probably use v4 to talk to that service.  And if = the service is v6-only, and 6to4 is the best way of getting there that's = available, you might as well try to use = it.

Further, I don't = buy the "separate tunnel to every host..." thing. Tunneled IPv6 = connectivity is widely available. All any developer needs to do if they = can't get Native IPv6 and a tunneled application is deemed good enough = for their testing purposes is connect both ends of their testing = environment to their choice of tunnel broker, and through the magic of = the internet, they're all connected to one = another.

You seem to have this = fixed idea of how applications should be tested and used, that is = inconsistent with my experience.  "Both" ends of their testing = environment?  What gives you the idea that there are only two ends? =   Distributed development projects are quite commonplace, and can = involve hundreds or even thousands of people, each at different sites. =   Nor is there necessarily some sort of central network that = everything connects to.  Nor should there = be. 

KM> - = Enterprises have applications that need to be able to communicate with = large numbers of hosts spread over a diverse area.  IPv6 is clearly = the way that they want to go, but it's not widely available at present. =  6to4 provides them with a means of routing traffic to their hosts = in the interim until widespread support for IPv6 exists.

WEG> = So do IPv6IP or GRE tunnels. Been using one at home for 3+ years now. = And honestly, if this type of application is going to be = enterprise-class, it needs to be in conjunction with ISP deployment of = IPv6, not in spite of it.

What = you're saying is that applications developers shouldn't bother with = actually trying to use IPv6 until the ISPs get their act together and = deploy it.  Well guess what?  The ISPs have let us down. =  We've been waiting for 15 years for the ISPs to roll out IPv6, and = for most of those 15 years they were all telling us that there were no = applications for it.  Now the ISPs are scrambling to get IPv6 into = their networks, and they want to sabotage the IPv6 mechanisms that we = have in place even before they are actually offering = product.

KM> - = Users (including enterprise users) who have small networks with IPv4 = access (generally behind v4 NATs) can use 6to4 to allow them to remotely = access individual hosts on those networks.  This can be done either = with a NAT that also acts as a v6 router and supports 6to4 as an = external connection, or by configuring the NAT to pass protocol 41 to a = IPv6 router for the network, internal to the v4 NAT.

WEG> = Until CGN becomes common, in which case 6to4 doesn't work again. Also, = that same NAT + v6 router combination could just as easily manage a = static tunnel.

You're missing = something.   I can connect directly from my mobile laptop to a = machine in my home network using 6to4.  I didn't have to set up any = static tunnel for either one.  Sure, I could do that, I could get = tunnels from HE or some other source and route through them.  Why = should I bother?  Why do I want to make my IPv6 traffic take any = longer a route than necessary?  You've argued against 6to4 with = relay routers because it's routing can be suboptimal, but the same is = true of any other tunneling scheme.

KM>Widespread IPv6 support for native IPv6 would = be when native IPv6 is available everywhere that IPv4 access is = available, from at least one provider, with quality (connectivity, = reliability, support) approximately as good as IPv4, and at a reasonable = price.  In other words, you can't expect applications to rely on = native IPv6 until it's reliably available everywhere that they need to = use it.

WEG> So Widespread IPv6 has to have reliability and = support equivalent to IPv4, yet you're saying that you can expect = applications to rely on 6to4 in the meantime despite evidence that it's = unreliable, and the virtual guarantee that it won't be supported by the = upstream ISP?

There's no such = virtual guarantee.   

And you and I disagree about the definition of = widespread. I do not think that widespread means "every small ISP in = every corner of the world supports it ubiquitously and at every price = point." I think it means "it's available for a majority (>50%) of = Internet service customers."

We can = disagree about the meaning of the word "widespread", but the practical = fact is that you can't expect people to give up something that works for = them until you can provide them something that works better for them. =  "Available to 50% of Internet service customers" is equivalent = to a very small percent probability of native connectivity being able to = replace 6to4 connectivity in a scenario where 6to4 is currently working. =  And the more hosts involved, the smaller that probability = is. 

WEG> = As was discussed in the WGLC for this document, enterprise applications = will not realistically use 6to4 as a means to reach IPv6 for business = critical applications. It's simply not reliable enough. It's also = probably unlikely that those will go directly to IPv6-only vs using = dual-stack to ease that transition. Individuals and Enterprises that use = IPv6-only applications will need to make IPv6 service a non-negotiable = requirement for their ISPs, networks, and devices rather than hoping = that 6to4 works.

KM> With respect, the v6ops working group is = not in a good position to judge whether enterprise applications will use = 6to4.   Operators rarely have a good understanding of what = individual application users or developers need.  They tend to = focus mostly on the applications that generate the most traffic, =  or cause them particular amounts of trouble, or the ones that = their biggest customers need.  Problem is, those aren't the only = applications that are important.  Every application is important to = its users, no matter how much or little traffic (or revenue) it = generates.

WEG> I'm not going to touch the "operators don't = know what they're talking about" part of your comment, except to note = that it's a gross generalization that won't help your argument, and = wonder how you are uniquely qualified to know better than the rest of = us...

Seems to me it's the v6ops = people who are making the gross generalizations.  I'm mostly = pointing out exceptions to those gross generalizations that have been = made here and in v6ops.  

I am simply saying that I do not for a second = believe that those same applications that are so important to that user = community are at the same time unimportant enough that they're the = sacrificial lamb that has to go IPv6-only when the majority of that user = community, no matter how small, doesn't have native IPv6 access yet. =

You have absolutely no idea which = applications will be important to the user community tomorrow.   = Who knows what will be the next netflix, twitter, facebook, youtube, ... = ?   The Internet is successful not because it supports some small = number of apps that operators think are a good idea; it's successful = because it (at least as originally architected) can support a wide range = of apps without operators having to bless = them. 

This is the essence = of the IPv6 content vs access chicken/egg problem, and 6to4 absolutely = will not break the impasse. 6to4 breakage is the most common thing that = content providers cite as reasons why they don't just go dual-stack. Why = would an enterprise application be any = different?

It doesn't really matter = much whether "content-providers" (as in web site providers) go "dual = stack" now.  Sure, they need to be gearing up for it, making sure = that they understand it, making sure that their networks support it. =  (Or maybe they'll just install v6-to-v4 proxies at their borders = so that they can keep providing good customer service in the face of = LSN-induced brain damage on the public v4 network.)   But assuming = their applications work through LSN, they're going to keep supporting v4 = for a long time anyway, because that's the established base of = interoperability for their products and services.   Existing = "content providers" are not going to drive adoption of IPv6.   = They're going to follow it.  Web and email will be the last = applications to migrate.  New content might appear on v6, and that = might drive adoption.  But to the extent that it drives adoption, = it probably won't be from the currently established players that already = have plenty of v4 addresses and infrastructure.  It will be from = new things that take advantage of the niches created by IPv6 that didn't = exist before.

KM> 6to4 = is as reliable as IPv4 is, if it isn't asked to cross a relay = router.
WEG> perhaps (with the exception of MTU issues that plague = any tunneled protocol), but you continue to not provide any examples of = this being used anywhere, in the face of significant evidence that 6to4 = is horribly unreliable *with* a relay. So this gets filed in the same = place as my 100% secure file server which happens to be unplugged from = power and network and encased in 10ft of concrete. Theoretically = perfect, but otherwise practically = useless.

What is "anywhere" to = you?  You seem to have a content-centric view of the Internet. =  I do not.   Meanwhile, you persist in saying that something = that I've used regularly for more than 10 years, to do useful work, = isn't being used anywhere.   I keep seeing figures that 6to4 = comprises 40-some-odd percent of IPv6 traffic, while native IPv6 is = around 10 percent.  By your logic, native v6 should be deprecated = because it doesn't work reliably and it's not being used = anywhere.

KM> And = there are valid reasons to use 6to4 even where IPv4 connectivity already = exists.
WEG> One would hope you wouldn't be trying to use 6to4 = where IPv4 connectivity *doesn't* = exist.

Right, but the point is = that there are valid use cases for 6to4 even where you have IPv4 = connectivity for part or even all of the network that you're = using.

KM>Even in = cases where 6to4 traffic must cross a relay router, sometimes it's the = best solution available.
WEG> Perhaps, but again, we're talking = about such a small percentage of the time that the cure ends up being = worse than the disease. I love orphans and lost causes as much as the = next guy, but really...

The disease = is the current IPv4 network with NATs and LSNs and a paucity of address = space.  6to4 is like a drug that can let some valuable v6 = applications grow (even if a bit stunted) and survive until there's once = again a network that will support them.  Sure, there are some side = effects and contraindications.  But it's useful when used with = awareness of its limitations.  You're arguing that it should be = discouraged because it causes some problems.  Indeed it does. =  But LSN also causes problems, and is a bigger dead-end than 6to4, = and it's full steam ahead with that.  At least 6to4 is designed to = ease transition to a saner world, which is a lot more than I can say for = LSN.

KM>All of the = criticisms in section 3 have to do with the use of relays to exchange = traffic between 6to4 and native IPv6.   In many cases the = criticisms are overbroad.   Not all uses of 6to4 involve = relays.  For some of those that do need to use relays, it is not = necessarily the case that the relay is operated by an unknown = third-party.

WEG> Again, please substantiate this with = examples of implementations that are actively using non-relay 6to4. =  Also, the number of applications of 6to4 that can be guaranteed to = avoid any unknown 3rd party relays is extremely limited due to the = nature of anycast and 6to4's asymmetric routing.  The protocol = action requested in this draft in no way prevents one or more consenting = networks from using 6to4 and continuing to run relays for their local = traffic indefinitely - in fact, it even provides a reference to a = document to show them how to make it work as well as possible. It is = simply saying that it's not a good = idea.

KM> Application implementations shouldn't care = whether they're using relay 6to4, non-relay 6to4, or 6to4 at all. =  Application implementations should at most care that they're using = IPv6 rather than IPv4, and for some applications even this is not = appropriate.
Application deployments might well need to care how well = their underlying networks work.  Ideally, they shouldn't have to = care, but that's the world we're currently living in.

WEG> = First, you're hair-splitting between implementation and deployment. = However you want to call it, I'm referring to "situations" where 6to4 is = in use without relays and is performing reliably on a business-critical = use to justify your assertion that we shouldn't toss out this part of = 6to4 along with the anycast/relay part because it's still so = useful.

You're attacking 6to4 on = the basis of irrelevancies.  As for business-critical, that's up to = the business using it to determine whether it works well enough for = their purposes.  There are a lot of technically dubious practices = used in business critical applications and = networks.

WEG> I agree = that properly written applications are IP version-agnostic. There is = only a question of whether they work through one or more layers of IPv4 = NAT, or they don't. If they don't, then the solution is IPv6. If IPv6 = isn't available, you have many major content providers saying that they = absolutely don't see 6to4 as an acceptable substitute, meaning that your = supposed application of 6to4 as a fix for this problem is so niche as to = be harmful rather than helpful. =

The notion that "properly written = applications are IP version-agnostice" is naive and overbroad. =  IPv6 works differently enough from IPv4 that many applications = cannot treat them the same.   Simple client-server apps, perhaps, = can ignore their differences, but that's just a corner case. =   

I have no doubt that many of those = "major content providers" are correct when they don't see 6to4 as an = acceptable substitute for them.  But the Internet doesn't exist = just to support "major content providers".  So stop trying to = sabotage something that works well enough for other = users.

Why are we having a World = IPv6 Day? In part to shake loose the broken 6to4 users that may not even = know that 6to4 is enabled/broken so that content providers can be more = confident that they can dual-stack their websites without risk of = significant user impact due to = breakage.

I'm looking forward = to World IPv6 Day, and what will be learned from it.   But again, = how well 6to4 works with "major content providers" is = irrelevant.

KM> The requested = protocol action deprecates 6to4 and discourages its inclusion in future = implementations.  That's harmful to applications and users for whom = native IPv6 isn't available - which is to say, pretty much everyone at = the moment.  When native IPv6 becomes widely available, it will = then be appropriate to transition hosts and networks using 6to4 to = native IPv6.  But even then, there will probably still be a need = for host implementations

WEG> Well, it'd be more harmful if = there weren't alternatives.

There = aren't any good ones.  Teredo and configured tunnels are worse in = many ways; though they each have their use cases. =   

Also, assuming that = the protocol is declared historical, we're now in a footrace between = ISPs deploying IPv6 and equipment vendors removing support for 6to4 (or = rolling out new products that don't support it in the first place). I = think you're oversensationalizing both the impact of this draft and the = lack of IPv6, given that nearly all major ISPs in the commercial space = are currently offering or have a timeline to offer Native IPv6, and a = large amount of the ISPs in the residential space have a timeline for = deployment, many have already started trials.
Finally, we're having = problems with equipment that doesn't support IPv6 at all. 6to4 is not = high on the priority list to implement compared with a functional IPv6 = stack, meaning that on new gear, it likely won't get implemented until = it's no longer necessary.

Gear that = doesn't support IPv6 by now is pretty odd gear.     But I'm = not going to tell you not to use it.  I'm just saying, if you want = odd gear to work for you in your own specific use cases, don't try to = sabotage other odd things that work for other people in their specific = use = cases.

Keith

= --Apple-Mail-18-614669036-- From fernando.gont.netbook.win@gmail.com Tue Jun 7 23:25:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3AC11E807E for ; Tue, 7 Jun 2011 23:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYOqsAkYk7Nd for ; Tue, 7 Jun 2011 23:25:52 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD4A611E8071 for ; Tue, 7 Jun 2011 23:25:51 -0700 (PDT) Received: by gwb20 with SMTP id 20so95571gwb.31 for ; Tue, 07 Jun 2011 23:25:51 -0700 (PDT) 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:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=EMeHrv56dgMmsMkhFsO/E+j4P4gAtdk42DnYBG4sgKc=; b=rF7ufecA0MPXkCsb0k1lGB3CJYf5lNiuyScS0pcuL+hNcI7laS74DVhCXvvjWP0nc7 cWYQO6CXkSyue2mgyzLF/fLxl5IWaXE9cKsRWaatdHaqiT/VVOnqRZ41lf+9grmZ5zeg 1EDCXnY76W/Bx5UeokT/6OU1AP8EGb+F+77aw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=h2ALJtRTNascMkjLIiiEhkYMljm5clM90XXZc3KRlC/5YETb3pTYn/x6Jb1NoyjFQC 72f9f/Ki7Xhw+TUD6NtYOqrmnesz6nQ6dHxyznhzw9wtvaCFGlYrilE72oBW6WHxjeUa g9yseF1oFgF8ijEhHxYND9/bpeERsxbp/rw/A= Received: by 10.101.10.17 with SMTP id n17mr5690246ani.34.1307514351190; Tue, 07 Jun 2011 23:25:51 -0700 (PDT) Received: from [192.168.123.103] ([190.48.238.249]) by mx.google.com with ESMTPS id x14sm250518ani.33.2011.06.07.23.25.49 (version=SSLv3 cipher=OTHER); Tue, 07 Jun 2011 23:25:50 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DEF15E2.4070508@gont.com.ar> Date: Wed, 08 Jun 2011 03:25:38 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: IPv6 Operations X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] New revision of draft-gont-v6ops-ra-guard-evasion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 06:25:52 -0000 Folks, I've just posted a revision of the aforementioned I-D. It is available at: http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt This revision hopefully addresses the comments I have received so far (and also fixes a few errors I spotted in the previous version). Any further comments will be very welcome. 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 fernando.gont.netbook.win@gmail.com Wed Jun 8 01:36:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39DC11E8111; Wed, 8 Jun 2011 01:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+Mo7kXGuC2H; Wed, 8 Jun 2011 01:36:38 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25D2311E809C; Wed, 8 Jun 2011 01:36:38 -0700 (PDT) Received: by gxk19 with SMTP id 19so137699gxk.31 for ; Wed, 08 Jun 2011 01:36:37 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=/74x3nA5p9xC0Rt7Q/i1x3BAzTSOxjjgKxl1riGTZxg=; b=Zt8FMZIH7E4ZfvdpC+Jqhy5d6ZYn73P8A6JD0d1o9lUyO87VBVnmYOxFfVC2/Eit+v Bktp6WG4fqgQ3ODhezL1wydGPFYp8GL/AwKN/QJKeTtwOaIp0d9I3+vLQNZVgXOOjNPl utYlq+PjqgYPlVQOJQVTWzZPoclko0rvFXDyQ= 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:content-type :content-transfer-encoding; b=JT0RIs2LarK++Pkkb7EdpclHKmhEq+UvtwxyV4gvzkplMTGrZs/Dc3bGRvqRrzUpJ6 HcRPzJJIMakINzRQcAuzRdvESe87jUzgYOLCTILNdfNNFv378asBQ0T9bVZONSzhdA00 Q10jwaDG19JlmyAQxHUHbCZqc9+7YdvcjWx5Y= Received: by 10.91.26.23 with SMTP id d23mr368746agj.73.1307522197524; Wed, 08 Jun 2011 01:36:37 -0700 (PDT) Received: from [192.168.123.103] ([190.48.238.249]) by mx.google.com with ESMTPS id c21sm339717ana.50.2011.06.08.01.36.33 (version=SSLv3 cipher=OTHER); Wed, 08 Jun 2011 01:36:35 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DEF3461.8040502@gont.com.ar> Date: Wed, 08 Jun 2011 05:35:45 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Pekka Savola References: <4DE6DD93.507@gont.com.ar> <4DE7D813.3050700@gont.com.ar> <201106021939.p52Jd8rI002414@cichlid.raleigh.ibm.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 08:36:38 -0000 Hi, Pekka, On 06/06/2011 07:43 AM, Pekka Savola wrote: >> RA-Guard is not a perfect solution to RA spoofing. It never will >> be. It has limitations (and always will). ND packets that using >> extension headers or fragmentation are just one specific example. > > This has happened with radvd. You mean that at some point radvd was sending fragmented IPv6 traffic, even when it was "unexpected"? > There was one individual who very strongly insisted (by filing and > bugging about that in a bug report at Red Hat Bugzilla) that he must be > able to advertise his whole /48, i.e., 64K prefix information options. > That resulted in the implementation fragmenting packets at the IP > layer. Transport layer would fragmentation to multiple RAs would have > been possible as well but there was no point in implementing that. I > solved the "problem" by restricting radvd send buffer size to 1452B, so > both are prevented. I wouldn't be sad to see the RA transport/IP layer > fragmentation go. This is a good datapoint to have (i.e., radvd never sending fragmented ND traffic) -- I will try to include a note about this in the next rev of the I-D. 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 mrex@sap.com Wed Jun 8 08:42:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA5611E8182; Wed, 8 Jun 2011 08:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.88 X-Spam-Level: X-Spam-Status: No, score=-8.88 tagged_above=-999 required=5 tests=[AWL=1.369, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNYPWOvFgkD9; Wed, 8 Jun 2011 08:42:18 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 18FCF11E8158; Wed, 8 Jun 2011 08:42:17 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p58FgAih028962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Jun 2011 17:42:15 +0200 (MEST) From: Martin Rex Message-Id: <201106081542.p58FgAcs022229@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Wed, 8 Jun 2011 17:42:10 +0200 (MEST) In-Reply-To: <201106071850.p57IoDhb011453@fs4113.wdf.sap.corp> from "Martin Rex" at Jun 7, 11 08:50:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: v6ops@ietf.org, ietf@ietf.org Subject: Re: [v6ops] Last Call: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 15:42:19 -0000 I'm sorry, I seem to have goofed up during mail editing... I meant to write that cassifying 6to4 as historic is INappropriate use of the IETF process in the last sentence. -Martin Martin Rex wrote: > > George, Wesley wrote: > > > > > It's time to remove the stabilisers on the IPv6 bicycle. > > > > This takes nothing away. It's not as if the day that this draft gets > > published as an RFC, 6to4 stops working. > > > In my personal perception, the "historic" status used to be a technical > characterization to indicate that > > (1) a protocol or technology has been fully replaced by some newer > protocol and there is no reason to continue using the original > technology anymore because the successor can be used in each > of the original usage scenarios today > > (2) the protocol/technology has been largely put out of use, and its > active use has dropped to marginal levels (like less than 1% of the > original active use) > > Personally, I have never conciously used anything related to IPv6 so > far, so for me it is difficult to comment, but what has been said > looks to me that neither (1) nor (2) apply to 6to4. > > The user base seems to have always been small, and most of the users > of 6to4 simply did _not_ have an alternative -- and its current > users still do _not_ have an alternative today. > > Classification of 6to4 as historic is appropriate use of the IETF process, > because it would be a political, but not an accurate technical statement. > > > -Martin From jnc@mercury.lcs.mit.edu Wed Jun 8 09:04:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C6711E8142; Wed, 8 Jun 2011 09:04:17 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VahQG86UmOI; Wed, 8 Jun 2011 09:04:16 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF4511E8158; Wed, 8 Jun 2011 09:04:15 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1F8CF18C121; Wed, 8 Jun 2011 12:04:15 -0400 (EDT) To: ietf@ietf.org, v6ops@ietf.org Message-Id: <20110608160415.1F8CF18C121@mercury.lcs.mit.edu> Date: Wed, 8 Jun 2011 12:04:15 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [v6ops] Last Call: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 16:04:17 -0000 > From: Martin Rex > Classification of 6to4 as historic is [in]appropriate use of the IETF > process, because it would be a political .. statement. Well, we've never done _that_ before, have we? Wouldn't want to set an unfortunate precedent. Noel From jhw@apple.com Wed Jun 8 09:17:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59A911E81D7; Wed, 8 Jun 2011 09:17:44 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5pmuyC+af5o; Wed, 8 Jun 2011 09:17:43 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 709B411E81D5; Wed, 8 Jun 2011 09:17:43 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LMH002P3BW0AKF1@mail-out.apple.com>; Wed, 08 Jun 2011 09:17:41 -0700 (PDT) X-AuditID: 11807134-b7c00ae0000074fb-f9-4defa0a49e7e Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 86.4E.29947.5A0AFED4; Wed, 08 Jun 2011 09:17:41 -0700 (PDT) Received: from event-10-1-91-170.venue.apple.com (unknown [192.42.249.91]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LMH00JOYBXGRQ40@cardamom.apple.com>; Wed, 08 Jun 2011 09:17:40 -0700 (PDT) From: james woodyatt In-reply-to: <20110608160415.1F8CF18C121@mercury.lcs.mit.edu> Date: Wed, 08 Jun 2011 09:17:41 -0700 Message-id: <49D685CB-00FD-42E5-9AD8-15E51545D9A2@apple.com> References: <20110608160415.1F8CF18C121@mercury.lcs.mit.edu> To: ietf@ietf.org X-Mailer: Apple Mail (2.1237.1) X-Brightmail-Tracker: AAAAAA== Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 16:17:45 -0000 On Jun 8, 2011, at 9:04 AM, Noel Chiappa wrote: > From: Martin Rex >> >> Classification of 6to4 as historic is [in]appropriate use of the IETF process, because it would be a political .. statement. > > Well, we've never done _that_ before, have we? Wouldn't want to set an unfortunate precedent. I see no reason for IETF to avoid setting standards for layer-9 protocols. -- james woodyatt member of technical staff, core os networking From behcetsarikaya@yahoo.com Wed Jun 8 09:41:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E238711E814D for ; Wed, 8 Jun 2011 09:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbvLcJTsO3cF for ; Wed, 8 Jun 2011 09:41:17 -0700 (PDT) Received: from nm27-vm5.bullet.mail.ne1.yahoo.com (nm27-vm5.bullet.mail.ne1.yahoo.com [98.138.91.249]) by ietfa.amsl.com (Postfix) with SMTP id 6ED3811E8116 for ; Wed, 8 Jun 2011 09:41:17 -0700 (PDT) Received: from [98.138.90.56] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jun 2011 16:41:14 -0000 Received: from [98.138.87.11] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jun 2011 16:41:14 -0000 Received: from [127.0.0.1] by omp1011.mail.ne1.yahoo.com with NNFMP; 08 Jun 2011 16:41:06 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 745677.58180.bm@omp1011.mail.ne1.yahoo.com Received: (qmail 31907 invoked by uid 60001); 8 Jun 2011 16:41:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307551266; bh=IOStDo0+jiJQSEfirk+YfHiqyR6TzCo01VQwiUUEhJQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=JTm+3z2ndCkC8xqtp3vMS32WetsLgsM7ceMqSdEnkyPAnbh5hR1eRrXXioSRyTsbZt/OAZAC63mzgQq2krtN1lSGd6OUg4TZbE42XS+RGGBje7XZ9bUvVupnXggU1kA6I1ylYt4NRSTwCym0HQTi/mZJSgTDJggerh7dszyiHy4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Zmxc37bE6huh2bwNJe1WtUf2ZnEv5aG0s92/FZOcapPUtApsYIqgVKPcBL6RWg6I3IvvJxfDcKAHhqiReK8gSn7GJgsOg15HosP0PUWyV+jpR8Jz+BHHn6VuDq3E3HHm6j1rx0tw1xvjpfGfgQ/CMVMO8rlLV0r3CAyeS3SlpeM=; Message-ID: <329322.31236.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: nj2Sg6gVM1njvMmkbIeih8kbwdQktBJugkHRymFbgRHGhbk DsOh9JjYXWKgdQSgD81QYgEgNiRtReuooL170YJpC.J4YE9jiOy1tYgIyj.o HNF3tNCX5lEvE1t6fpfL14c3GpDnBr0BNGlRJ0h_kJndyXU13FUn4g56PfzX F7Z7yns_KgYrAc_oL5S7XaryxXqANsq3LSlW6.Z__29KzxPXg7nVYkTJEZmx C9BoN_qllkshD_2gAwfsfUcoIcbmUKRABZYoh5FCe3WTnTtmMi72GosfRtVk Dav06NDM1jw.tiRuT6CyY_zI9Aw1zqHjdZckid13JyN3NpmF6940MjipIYSk FgGFK2rA0eSJ2GVs3A7mVopzN4S8Ct66uy40YeBfvhXu03NUyb99c2qvju0m .Xa83DO5CmMNQyQ-- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Wed, 08 Jun 2011 09:41:06 PDT X-Mailer: YahooMailRC/570 YahooMailWebService/0.8.111.304355 Date: Wed, 8 Jun 2011 09:41:06 -0700 (PDT) From: Behcet Sarikaya To: IPv6 Operations MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [v6ops] New Version Notification for draft-sarikaya-v6ops-prefix-delegation-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 16:41:19 -0000 A new version of I-D, draft-sarikaya-v6ops-prefix-delegation-06.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: draft-sarikaya-v6ops-prefix-delegation Revision: 06 Title: DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile Networks Creation date: 2011-06-06 WG ID: Individual Submission Number of pages: 13 Abstract: As interest on IPv6 deployment is increasing in cellular networks several migration issues are being raised and IPv6 prefix management is the one addressed in this document. Based on the idea that DHCPv6 servers can manage prefixes, we address prefix management issues such as the access router offloading delegation and release tasks of the prefixes to a DHCPv6 server using DHCPv6 Prefix Delegation. The access router first requests a prefix for an incoming mobile node from the DHCPv6 server. The access router may next do stateless or stateful address allocation to the mobile node, e.g. with a Router Advertisement or using DHCP. We also describe prefix management using Authentication Authorization and Accounting servers. The IETF Secretariat From brian.e.carpenter@gmail.com Wed Jun 8 10:52:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB22511E8125; Wed, 8 Jun 2011 10:52:52 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TelmRgEVz0yo; Wed, 8 Jun 2011 10:52:52 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 041F111E8076; Wed, 8 Jun 2011 10:52:51 -0700 (PDT) Received: by fxm15 with SMTP id 15so574315fxm.31 for ; Wed, 08 Jun 2011 10:52:51 -0700 (PDT) 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=7x+fiy/1CXZMidDy3X1YCnNBKxDxJgIoeziR6mxgcgA=; b=cdYoYRj3nwl4fVXf2D0lDjtlSI9ufyyeuMspmrKKBGPBNJ+HDB+vYJ/rUUDBFYciJQ EWy/lO/d6u943ipiGPQdx2ib0QO3kjTx0BViw5mLxpXlah+TmYHmxTwhOuWQzg43zvAw E2R7Aay+K1CwUKEF8AmfyMfnssSvu4GsFSYM8= 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=nxKnahLzMwBMDnxvlA57ARnE4ZBgKezw2belrYZ+JTZ7o/q95m/ixhUC/+4jaVLDRw fotUcoGMdNVw2IKYiPPMsLZ+M/ol21Z9g3VKmqy1SFGQQlZGGl+Ajba+FS9i19TscMJF wMUqi5KXlm4O4QfIKTzAmT9AF4VB4ZF7fW8KY= Received: by 10.223.97.142 with SMTP id l14mr1133108fan.137.1307555570771; Wed, 08 Jun 2011 10:52:50 -0700 (PDT) Received: from [10.255.25.89] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id q21sm330138fan.40.2011.06.08.10.52.47 (version=SSLv3 cipher=OTHER); Wed, 08 Jun 2011 10:52:49 -0700 (PDT) Message-ID: <4DEFB6EB.8020103@gmail.com> Date: Thu, 09 Jun 2011 05:52:43 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt References: <20110608160415.1F8CF18C121@mercury.lcs.mit.edu> <49D685CB-00FD-42E5-9AD8-15E51545D9A2@apple.com> In-Reply-To: <49D685CB-00FD-42E5-9AD8-15E51545D9A2@apple.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , ietf@ietf.org Subject: Re: [v6ops] Last Call: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 17:52:55 -0000 On 2011-06-09 04:17, james woodyatt wrote: > On Jun 8, 2011, at 9:04 AM, Noel Chiappa wrote: >> From: Martin Rex >>> Classification of 6to4 as historic is [in]appropriate use of the IETF process, because it would be a political .. statement. >> Well, we've never done _that_ before, have we? Wouldn't want to set an unfortunate precedent. > > I see no reason for IETF to avoid setting standards for layer-9 protocols. In any case, I don't see the politics, unless (for example) declaring RFC 1267 Historic was politics too. Brian From wesley.george@twcable.com Wed Jun 8 12:28:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC81F11E8174; Wed, 8 Jun 2011 12:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.82 X-Spam-Level: X-Spam-Status: No, score=0.82 tagged_above=-999 required=5 tests=[AWL=-0.833, 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_32=0.6, J_CHICKENPOX_54=0.6, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbnj-df0GHQg; Wed, 8 Jun 2011 12:28:31 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 40E0711E8171; Wed, 8 Jun 2011 12:28:30 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,339,1304308800"; d="scan'208,217";a="222344242" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 08 Jun 2011 15:28:19 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 8 Jun 2011 15:28:13 -0400 From: "George, Wesley" To: Keith Moore Date: Wed, 8 Jun 2011 15:28:09 -0400 Thread-Topic: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC Thread-Index: AcwlZPBC7XzsEcC/TfeWF6uzHBmZ5wAigcnA Message-ID: <34E4F50CAFA10349A41E0756550084FB0690A2B5@PRVPEXVS04.corp.twcable.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> In-Reply-To: <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_34E4F50CAFA10349A41E0756550084FB0690A2B5PRVPEXVS04corpt_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "ietf@ietf.org" Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 19:28:40 -0000 --_000_34E4F50CAFA10349A41E0756550084FB0690A2B5PRVPEXVS04corpt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Keith Moore [mailto:moore@network-heretics.com] Sent: Tuesday, June 07, 2011 6:48 PM To: George, Wesley Cc: ietf@ietf.org; v6ops@ietf.org Subject: Re: [v6ops] Last Call: = (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Histo= ric status) to Informational RFC KM>I've been using 6to4 on a regular, often daily, basis since the late 199= 0s. 6to4 has allowed me to develop IPv6 applications and test them on rea= l networks, and deploy them in limited circumstances. 6to4 has also allowe= d me to remotely access computers on my SOHO networks, using any applicatio= n protocol that I chose to do so, with out-of-the-box hardware and software= , without any application-specific proxies, and generally without any appli= cation-specific configuration. None of these scenarios required a relay ro= uter. All of them were, and continue to be, useful. KM> Yes, I've experienced on many occasions that using 6to4 to access dual-= stack web servers doesn't always work so well. Sometimes it picks a subopt= imal path because the relay router isn't convenient. Sometimes the v6 path= doesn't work at all and the application has to time out and retry using v4= . But this never really bothered me much, because my purpose in using 6to= 4 wasn't to try to access services that I could get to via IPv4 anyway. An= d neither, I suggest, is that a reasonable metric for evaluating 6to4 or an= y other IPv6 transition mechanism. The metric for evaluating an IPv6 tran= sition mechanism should be based on its effectiveness in accessing services= that are IPv6 only. WEG> Again, are you or are you not using a relay router? You keep going bac= k and forth. Bluntly, this isn't about whether you, or anyone else at IETF use 6to4. We = are the longest of the long tail; the smallest percentage, the exception to= the rule, not the exception that proves the rule. We're network geeks; we'= re willing to deal with dodgy connectivity or otherwise fiddly methods of d= oing things to test them and to prove a point. This discussion cannot be ab= out whether the protocol should be preserved because some marginal percenta= ge of folks in IETF use 6to4 successfully. I am not disagreeing that for so= me value of "work" 6to4 works to reach IPv6-only things. What I am saying i= s that the very things you illustrate here make it only acceptable for test= ing, and not for any sort of real substitute for IPv6 connectivity. What us= er is going to accept +100ms in latency due to suboptimal relay choice, or = waiting multiple seconds for IPv6 to time out because 6to4 didn't work in t= hat particular network setup? I think that the evidence says that 6to4 is a= ctually *ineffective* by the evaluation you suggest - a good portion of the= time it either utterly fails or provides such degraded service that it may= as well not work. KM> - Enterprises have applications that need to be able to communicate wit= h large numbers of hosts spread over a diverse area. IPv6 is clearly the w= ay that they want to go, but it's not widely available at present. 6to4 pr= ovides them with a means of routing traffic to their hosts in the interim u= ntil widespread support for IPv6 exists. WEG> So do IPv6IP or GRE tunnels. Been using one at home for 3+ years now. = And honestly, if this type of application is going to be enterprise-class, = it needs to be in conjunction with ISP deployment of IPv6, not in spite of = it. KM> What you're saying is that applications developers shouldn't bother wit= h actually trying to use IPv6 until the ISPs get their act together and dep= loy it. Well guess what? The ISPs have let us down. We've been waiting f= or 15 years for the ISPs to roll out IPv6, and for most of those 15 years t= hey were all telling us that there were no applications for it. Now the IS= Ps are scrambling to get IPv6 into their networks, and they want to sabotag= e the IPv6 mechanisms that we have in place even before they are actually o= ffering product. WEG> Yes, yes, shame on the big, bad ISPs and their lack of deployment. Tru= st me, I'm as annoyed with the ISPs I've worked for and been a customer of = that it is taking so long to get IPv6 out there too. But...6to4 sabotaged itself. This draft is acknowledging reality that it re= ally didn't work the way we'd hoped. There is no active malevolence here on= the part of the ISPs. In fact many of them (us?) have deployed or will be = deploying 6to4 relays to improve the customer experience until native servi= ce is available, and are supporting the recommendations to make 6to4 suck l= ess in draft-carpenter. KM>Widespread IPv6 support for native IPv6 would be when native IPv6 is ava= ilable everywhere that IPv4 access is available, from at least one provider= , with quality (connectivity, reliability, support) approximately as good a= s IPv4, and at a reasonable price. In other words, you can't expect applic= ations to rely on native IPv6 until it's reliably available everywhere that= they need to use it. WEG> So Widespread IPv6 has to have reliability and support equivalent to I= Pv4, yet you're saying that you can expect applications to rely on 6to4 in = the meantime despite evidence that it's unreliable, and the virtual guarant= ee that it won't be supported by the upstream ISP? KM>There's no such virtual guarantee. WEG>I should probably have clarified that by "support" I don't mean "will p= ass protocol 41 IPv4 packets." I mean "can call and yell at someone when it= breaks." Make more sense now? WEG> I am simply saying that I do not for a second believe that those same = applications that are so important to that user community are at the same t= ime unimportant enough that they're the sacrificial lamb that has to go IPv= 6-only when the majority of that user community, no matter how small, doesn= 't have native IPv6 access yet. KM>You have absolutely no idea which applications will be important to the = user community tomorrow. Who knows what will be the next netflix, twitter= , facebook, youtube, ... ? The Internet is successful not because it supp= orts some small number of apps that operators think are a good idea; it's s= uccessful because it (at least as originally architected) can support a wid= e range of apps without operators having to bless them. WEG> One of the few places I'm in agreement with you. However, it's not a j= ustification for 6to4. It's a justification for ubiquitous IPv6. It's not a= bout whether the operators "bless" an application or not. If those up-and-c= oming applications are saddled with the performance hit that 6to4 represent= s, they are unlikely to be successful. In other words, 6to4 will not move t= he needle on innovative IPv6-only applications, so they're tied to the nati= ve IPv6 rollout schedule. Sad, but true. WEG>This is the essence of the IPv6 content vs access chicken/egg problem, = and 6to4 absolutely will not break the impasse. 6to4 breakage is the most c= ommon thing that content providers cite as reasons why they don't just go d= ual-stack. Why would an enterprise application be any different? KM> It doesn't really matter much whether "content-providers" (as in web si= te providers) go "dual stack" now. Sure, they need to be gearing up for it= , making sure that they understand it, making sure that their networks supp= ort it. (Or maybe they'll just install v6-to-v4 proxies at their borders s= o that they can keep providing good customer service in the face of LSN-ind= uced brain damage on the public v4 network.) But assuming their applicati= ons work through LSN, they're going to keep supporting v4 for a long time a= nyway, because that's the established base of interoperability for their pr= oducts and services. Existing "content providers" are not going to drive = adoption of IPv6. They're going to follow it. Web and email will be the = last applications to migrate. New content might appear on v6, and that mig= ht drive adoption. But to the extent that it drives adoption, it probably = won't be from the currently established players that already have plenty of= v4 addresses and infrastructure. It will be from new things that take adv= antage of the niches created by IPv6 that didn't exist before. WEG> This is a variant of the old "IPv6 Killer App" discussion. We're still= waiting for one, largely because people are afraid of excluding some non-t= rivial percentage of the populace from being able to use their new, cool th= ing because it's IPv6-only, and they don't think it will so compelling as t= o be a justification for people to find a workaround or clamor for IPv6 sup= port. IMO, IPv4 exhaustion and CGN is the closest thing we have to a Killer= App for IPv6. If 6to4 somehow provides an incentive for folks to generate = IPv6-only applications, and for ordinary users to start using 6to4 to conne= ct to IPv6, I'm wondering why it hasn't accomplished that goal in the last = 10 years?What would be different all of the sudden? KM> 6to4 is as reliable as IPv4 is, if it isn't asked to cross a relay rout= er. WEG> perhaps (with the exception of MTU issues that plague any tunneled pro= tocol), but you continue to not provide any examples of this being used any= where, in the face of significant evidence that 6to4 is horribly unreliable= *with* a relay. So this gets filed in the same place as my 100% secure fil= e server which happens to be unplugged from power and network and encased i= n 10ft of concrete. Theoretically perfect, but otherwise practically useles= s. KM>What is "anywhere" to you? You seem to have a content-centric view of t= he Internet. I do not. Meanwhile, you persist in saying that something t= hat I've used regularly for more than 10 years, to do useful work, isn't be= ing used anywhere. WEG> No, I'm trying to follow the same distinction you've drawn between 6to= 4 with relays and without and understand how that's being used, since appar= ently 6to4 without relays is a lot less problematic and you've had such suc= cess with it. What I've read is multiple people trying to explain to you th= at non-anycast 6to4 (3056) is not being used, and you continuing to insist = that it's heavily used by providing examples of 3068. KM> I keep seeing figures that 6to4 comprises 40-some-odd percent of IPv6 = traffic, while native IPv6 is around 10 percent. By your logic, native v6 = should be deprecated because it doesn't work reliably and it's not being us= ed anywhere. WEG> While my general view is that 40% of less than 1% of Internet traffic = amounts to a statistical anomaly, citation, please? Assuming that the sourc= e of your statistic is able to distinguish between types of protocol 41 tra= ffic, that 40% is almost definitely traffic that is using a relay, BTW. KM> The disease is the current IPv4 network with NATs and LSNs and a paucit= y of address space. 6to4 is like a drug that can let some valuable v6 appl= ications grow (even if a bit stunted) and survive until there's once again = a network that will support them. Sure, there are some side effects and co= ntraindications. But it's useful when used with awareness of its limitatio= ns. You're arguing that it should be discouraged because it causes some pr= oblems. Indeed it does. But LSN also causes problems, and is a bigger dea= d-end than 6to4, and it's full steam ahead with that. At least 6to4 is des= igned to ease transition to a saner world, which is a lot more than I can s= ay for LSN. WEG> LSN is a necessary evil brought on by the lack of ubiquitous IPv6 supp= ort, which has many causes. I don't like it either. The thing you are faili= ng to realize is that IETF saying that 6to4 use is a bad idea in no way sto= ps consenting adults from using it in spite of the side effects and contrai= ndications, but it does put a much finer point on those contraindications. KM> I have no doubt that many of those "major content providers" are correc= t when they don't see 6to4 as an acceptable substitute for them. But the I= nternet doesn't exist just to support "major content providers". So stop t= rying to sabotage something that works well enough for other users. WEG> Not trying to imply that it does. I'm saying that your definition of "= works well enough" and the average user's are widely different, making 6to4= a no-op for the average user. The content providers' position on end users= trying to use 6to4 to reach their content is an example of that point. WEG> Why are we having a World IPv6 Day? In part to shake loose the broken = 6to4 users that may not even know that 6to4 is enabled/broken so that conte= nt providers can be more confident that they can dual-stack their websites = without risk of significant user impact due to breakage. KM> I'm looking forward to World IPv6 Day, and what will be learned from it= . But again, how well 6to4 works with "major content providers" is irrele= vant. WEG> I might argue that this is because 6to4 is largely irrelevant and will= become increasingly more so as major ISPs roll out IPv6 in the next 12-18 = months. This is about removing barriers to deployment and use of IPv6 for t= he increasing population of Native IPv6 users, not trying to buff the turd = for a tiny (but unfortunately very vocal) minority. WEG>Finally, we're having problems with equipment that doesn't support IPv6= at all. 6to4 is not high on the priority list to implement compared with a= functional IPv6 stack, meaning that on new gear, it likely won't get imple= mented until it's no longer necessary. KM> Gear that doesn't support IPv6 by now is pretty odd gear. But I'm n= ot going to tell you not to use it. I'm just saying, if you want odd gear = to work for you in your own specific use cases, don't try to sabotage other= odd things that work for other people in their specific use cases. WEG> No. As have multiple others, you assume that I am talking about the us= ual suspects in core routing and enterprise-class networking and servers. T= he consumer electronics space is WOEFULLY behind by comparison. That's not = "odd" gear. And this isn't about me (for some value of me) wanting that gea= r to work for some corner case application. This is about me having to sup= port millions of customers who want that gear to work because they don't wa= nt to buy replacements for something that they see as working just fine tod= ay. See also CGN =3D necessary evil. Wes George ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_34E4F50CAFA10349A41E0756550084FB0690A2B5PRVPEXVS04corpt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

From: Keith Mo= ore [mailto:moore@network-heretics.com]
Sent: Tuesday, June 07, 2011 6:48 PM
To: George, Wesley
Cc: ietf@ietf.org; v6ops@ietf.org
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-histori= c-04.txt> (Request to move Connection of IPv6 Domains via IPv4 Clouds (6= to4) to Historic status) to Informational RFC

 

KM>I've been= using 6to4 on a regular, often daily, basis since the late 1990s.   6= to4 has allowed me to develop IPv6 applications and test them on real netwo= rks, and deploy them in limited circumstances.  6to4 has also allowed me to remotely access computers on my SOHO net= works, using any application protocol that I chose to do so, with out-of-th= e-box hardware and software, without any application-specific proxies, and = generally without any application-specific configuration.  None of these scenarios required a relay router. &nbs= p;All of them were, and continue to be, useful.

 

KM> Yes, I'v= e experienced on many occasions that using 6to4 to access dual-stack web se= rvers doesn't always work so well.  Sometimes it picks a suboptimal pa= th because the relay router isn't convenient.  Sometimes the v6 path doesn't work at all and the application has to= time out and retry using v4.   But this never really bothered me much= , because my purpose in using 6to4 wasn't to try to access services that I could g= et to via IPv4 anyway.  And neither, I suggest, is that a reasonab= le metric for evaluating 6to4 or any other IPv6 transition mechanism.  = ; The metric for evaluating an IPv6 transition mechanism should be based on its effectiveness in accessing services that = are IPv6 only.   

 <= /p>

WEG> Again, are you or= are you not using a relay router? You keep going back and forth.

Bluntly, this isn’t= about whether you, or anyone else at IETF use 6to4. We are the longest of = the long tail; the smallest percentage, the exception to the rule, not the exception that proves the rule. We’re network geeks; we̵= 7;re willing to deal with dodgy connectivity or otherwise fiddly methods of= doing things to test them and to prove a point. This discussion cannot be = about whether the protocol should be preserved because some marginal percentage of folks in IETF use 6to4 successfully. I= am not disagreeing that for some value of “work” 6to4 works to= reach IPv6-only things. What I am saying is that the very things you illus= trate here make it only acceptable for testing, and not for any sort of real substitute for IPv6 connectivity. What user i= s going to accept +100ms in latency due to suboptimal relay choice, or = waiting multiple seconds for IPv6 to time out because 6to4 didn’t wor= k in that particular network setup? I think that the evidence says that 6to4 is actually *ineffective* by the e= valuation you suggest – a good portion of the time it either utterly = fails or provides such degraded service that it may as well not work.

KM> - Enterprises have applications that need to = be able to communicate with large numbers of hosts spread over a diverse ar= ea.  IPv6 is clearly the way that they want to go, but it's not widely= available at present.  6to4 provides them with a means of routing traffic to their hosts in the interim until widesp= read support for IPv6 exists.

WEG> So do IPv6IP or GRE tunnels. Been using one at home for 3+ year= s now. And honestly, if this type of application is going to be enterprise-= class, it needs to be in conjunction with ISP deployment of IPv6, not in sp= ite of it.

 

KM> What you= 're saying is that applications developers shouldn't bother with actually t= rying to use IPv6 until the ISPs get their act together and deploy it. &nbs= p;Well guess what?  The ISPs have let us down.  We've been waiting for 15 years for the ISPs to roll out IPv6, and f= or most of those 15 years they were all telling us that there were no appli= cations for it.  Now the ISPs are scrambling to get IPv6 into their ne= tworks, and they want to sabotage the IPv6 mechanisms that we have in place even before they are actually offering pr= oduct.

 <= /p>

WEG> Yes, yes, shame o= n the big, bad ISPs and their lack of deployment. Trust me, I’m as an= noyed with the ISPs I’ve worked for and been a customer of that it is taking so long to get IPv6 out there too.

But…6to4 sabotaged = itself. This draft is acknowledging reality that it really didn’t wor= k the way we’d hoped. There is no active malevolence here on the part of the ISPs. In fact many of them (us?) have deployed or will be deploying= 6to4 relays to improve the customer experience until native service is ava= ilable, and are supporting the recommendations to make 6to4 suck less in dr= aft-carpenter.

 <= /p>

KM>Widespread IPv6 support for native IPv6 would = be when native IPv6 is available everywhere that IPv4 access is available, = from at least one provider, with quality (connectivity, reliability, suppor= t) approximately as good as IPv4, and at a reasonable price.  In other words, you can't expect applications= to rely on native IPv6 until it's reliably available everywhere that they = need to use it.

WEG> So Widespread IPv6 has to have reliability and support equivalent t= o IPv4, yet you're saying that you can expect applications to rely on 6to4 = in the meantime despite evidence that it's unreliable, and the virtual guar= antee that it won't be supported by the upstream ISP?

 

KM>There's n= o such virtual guarantee.   

WEG>I should probably = have clarified that by “support” I don’t mean “will= pass protocol 41 IPv4 packets.” I mean “can call and yell at s= omeone when it breaks.” Make more sense now?

WEG> I am si= mply saying that I do not for a second believe that those same applications= that are so important to that user community are at the same time unimport= ant enough that they're the sacrificial lamb that has to go IPv6-only when the majority of that user community, no= matter how small, doesn't have native IPv6 access yet.

 

KM>You have = absolutely no idea which applications will be important to the user communi= ty tomorrow.   Who knows what will be the next netflix, twitter, faceb= ook, youtube, ... ?   The Internet is successful not because it supports some small number of apps that operators think are= a good idea; it's successful because it (at least as originally architecte= d) can support a wide range of apps without operators having to bless them. 

WEG> One of the few pl= aces I’m in agreement with you. However, it’s not a justificati= on for 6to4. It’s a justification for ubiquitous IPv6. It’s not= about whether the operators “bless” an application or not. If those up-and-c= oming applications are saddled with the performance hit that 6to4 represent= s, they are unlikely to be successful. In other words, 6to4 will not move t= he needle on innovative IPv6-only applications, so they’re tied to the native IPv6 rollout schedule. Sad, but true.<= o:p>

 

WEG>This is = the essence of the IPv6 content vs access chicken/egg problem, and 6to4 abs= olutely will not break the impasse. 6to4 breakage is the most common thing = that content providers cite as reasons why they don't just go dual-stack. Why would an enterprise application be = any different?

 

KM> It doesn= 't really matter much whether "content-providers" (as in web site= providers) go "dual stack" now.  Sure, they need to be gear= ing up for it, making sure that they understand it, making sure that their networks support it.  (Or maybe they'll just install v6-to= -v4 proxies at their borders so that they can keep providing good customer = service in the face of LSN-induced brain damage on the public v4 network.) =   But assuming their applications work through LSN, they're going to keep supporting v4 for a long time anyway, b= ecause that's the established base of interoperability for their products a= nd services.   Existing "content providers" are not going to= drive adoption of IPv6.   They're going to follow it.  Web and email will be the last applications to migrate.  Ne= w content might appear on v6, and that might drive adoption.  But to t= he extent that it drives adoption, it probably won't be from the currently = established players that already have plenty of v4 addresses and infrastructure.  It will be from new things that tak= e advantage of the niches created by IPv6 that didn't exist before.

WEG> This is a variant= of the old “IPv6 Killer App” discussion. We’re still wai= ting for one, largely because people are afraid of excluding some non-trivi= al percentage of the populace from being able to use their new, cool thing be= cause it’s IPv6-only, and they don’t think it will so compellin= g as to be a justification for people to find a workaround or clamor for IP= v6 support. IMO, IPv4 exhaustion and CGN is the closest thing we have to a Killer App for IPv6. If 6to4 somehow provid= es an incentive for folks to generate IPv6-only applications, and for ordin= ary users to start using 6to4 to connect to IPv6, I’m wondering why i= t hasn’t accomplished that goal in the last 10 years?What would be different all of the sudden?

KM> 6to4 is as reliable as IPv4 is, if it isn't a= sked to cross a relay router.
WEG> perhaps (with the exception of MTU issues that plague any tunneled = protocol), but you continue to not provide any examples of this being used = anywhere, in the face of significant evidence that 6to4 is horribly unrelia= ble *with* a relay. So this gets filed in the same place as my 100% secure file server which happens to be unplug= ged from power and network and encased in 10ft of concrete. Theoretically p= erfect, but otherwise practically useless.

 

KM>What is &= quot;anywhere" to you?  You seem to have a content-centric view o= f the Internet.  I do not.   Meanwhile, you persist in saying tha= t something that I've used regularly for more than 10 years, to do useful work, isn't being used anywhere. <= o:p>

WEG> No, I’m try= ing to follow the same distinction you’ve drawn between 6to4 with rel= ays and without and understand how that’s being used, since apparentl= y 6to4 without relays is a lot less problematic and you’ve had such su= ccess with it. What I’ve read is multiple people trying to explain to= you that non-anycast 6to4 (3056) is not being used, and you continuing to = insist that it’s heavily used by providing examples of 3068.

 <= /p>

KM>  I = keep seeing figures that 6to4 comprises 40-some-odd percent of IPv6 traffic= , while native IPv6 is around 10 percent.  By your logic, native v6 sh= ould be deprecated because it doesn't work reliably and it's not being used anywhere.

WEG> While my general = view is that 40% of less than 1% of Internet traffic amounts to a statistic= al anomaly, citation, please? Assuming that the source of your statistic is able to distinguish between types of protocol 41 traffic, tha= t 40% is almost definitely traffic that is using a relay, BTW.

 

KM> The dise= ase is the current IPv4 network with NATs and LSNs and a paucity of address= space.  6to4 is like a drug that can let some valuable v6 application= s grow (even if a bit stunted) and survive until there's once again a network that will support them.  Sure, there are= some side effects and contraindications.  But it's useful when used w= ith awareness of its limitations.  You're arguing that it should be di= scouraged because it causes some problems.  Indeed it does.  But LSN also causes problems, and is a bigger dead-end than= 6to4, and it's full steam ahead with that.  At least 6to4 is designed= to ease transition to a saner world, which is a lot more than I can say fo= r LSN.

WEG> LSN is a necessar= y evil brought on by the lack of ubiquitous IPv6 support, which has many ca= uses. I don’t like it either. The thing you are failing to realize is that IETF saying that 6to4 use is a bad idea in no way stops co= nsenting adults from using it in spite of the side effects and contraindica= tions, but it does put a much finer point on those contraindications.

KM> I have n= o doubt that many of those "major content providers" are correct = when they don't see 6to4 as an acceptable substitute for them.  But th= e Internet doesn't exist just to support "major content providers".  So stop trying to sabotage something that works wel= l enough for other users.

WEG> Not trying to = imply that it does. I’m saying that your definition of “works w= ell enough” and the average user’s are widely different, making= 6to4 a no-op for the average user. The content providers’ position on end users trying to use 6to4 to reach their content is an example of th= at point.

WEG> Why are= we having a World IPv6 Day? In part to shake loose the broken 6to4 users t= hat may not even know that 6to4 is enabled/broken so that content providers= can be more confident that they can dual-stack their websites without risk of significant user impact due to breakage.

 

KM> I'm look= ing forward to World IPv6 Day, and what will be learned from it.   But= again, how well 6to4 works with "major content providers" is irr= elevant.

WEG> I might argue tha= t this is because 6to4 is largely irrelevant and will become increasingly m= ore so as major ISPs roll out IPv6 in the next 12-18 months. This is about removing barriers to deployment and use of IPv6 for the incr= easing population of Native IPv6 users, not trying to buff the turd for a t= iny (but unfortunately very vocal) minority.

WEG>Finally,= we're having problems with equipment that doesn't support IPv6 at all. 6to= 4 is not high on the priority list to implement compared with a functional = IPv6 stack, meaning that on new gear, it likely won't get implemented until it's no longer necessary.

 

KM> Gear tha= t doesn't support IPv6 by now is pretty odd gear.     But I'm not= going to tell you not to use it.  I'm just saying, if you want odd ge= ar to work for you in your own specific use cases, don't try to sabotage other odd things that work for other people in their speci= fic use cases.

WEG> No. As have multi= ple others, you assume that I am talking about the usual suspects in core r= outing and enterprise-class networking and servers. The consumer electronics space is WOEFULLY behind by comparison. That’s not ̶= 0;odd” gear. And this isn’t about me (for some value of me) wan= ting that gear to work for some corner case application. This is  abou= t me having to support millions of customers who want that gear to work because they don’t want to buy replacements for something th= at they see as working just fine today. See also CGN =3D necessary evil.

 

Wes George=


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_34E4F50CAFA10349A41E0756550084FB0690A2B5PRVPEXVS04corpt_-- From moore@network-heretics.com Wed Jun 8 13:19:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E848C21F85D1; Wed, 8 Jun 2011 13:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.081 X-Spam-Level: X-Spam-Status: No, score=-0.081 tagged_above=-999 required=5 tests=[AWL=-2.798, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ILu4z6jd4M7; Wed, 8 Jun 2011 13:19:15 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id AC44521F85CC; Wed, 8 Jun 2011 13:19:14 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id 7FF5920773; Wed, 8 Jun 2011 16:19:12 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 08 Jun 2011 16:19:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=z3stzUjtnjMm/mp+0TFJ2zEpOmI=; b=Op8Q1FZIUx0uOwY6LNQHUnhOqYskrMy8QIMbi7fipvztBWjk+YEXRARvyErPdNR2L7z6tjRqO3+4Wb9qx2J0DxZwwEFghHiUNSQFQGFALGp3UHeGbkfnfQqSEPN+HPxIX8QEtOjTviOK+c1hTWkgLkTGbl/CUQfi3zq1C8MzxyY= X-Sasl-enc: zPI7fwp8naEnG8L+cb9XjiOu9TX98R/ePcW9ASRgX7Li 1307564345 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 6CF904047BA; Wed, 8 Jun 2011 16:19:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-21-692146429 From: Keith Moore In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0690A2B5@PRVPEXVS04.corp.twcable.com> Date: Wed, 8 Jun 2011 16:19:04 -0400 Message-Id: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB0690A2B5@PRVPEXVS04.corp.twcable.com> To: "George, Wesley" X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , "ietf@ietf.org" Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 20:19:18 -0000 --Apple-Mail-21-692146429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 8, 2011, at 3:28 PM, George, Wesley wrote: > =20 > From: Keith Moore [mailto:moore@network-heretics.com]=20 > Sent: Tuesday, June 07, 2011 6:48 PM > To: George, Wesley > Cc: ietf@ietf.org; v6ops@ietf.org > Subject: Re: [v6ops] Last Call: = (Request to move Connection = of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to = Informational RFC > =20 > KM>I've been using 6to4 on a regular, often daily, basis since the = late 1990s. 6to4 has allowed me to develop IPv6 applications and test = them on real networks, and deploy them in limited circumstances. 6to4 = has also allowed me to remotely access computers on my SOHO networks, = using any application protocol that I chose to do so, with = out-of-the-box hardware and software, without any application-specific = proxies, and generally without any application-specific configuration. = None of these scenarios required a relay router. All of them were, and = continue to be, useful. > =20 > KM> Yes, I've experienced on many occasions that using 6to4 to access = dual-stack web servers doesn't always work so well. Sometimes it picks = a suboptimal path because the relay router isn't convenient. Sometimes = the v6 path doesn't work at all and the application has to time out and = retry using v4. But this never really bothered me much, because my = purpose in using 6to4 wasn't to try to access services that I could get = to via IPv4 anyway. And neither, I suggest, is that a reasonable metric = for evaluating 6to4 or any other IPv6 transition mechanism. The metric = for evaluating an IPv6 transition mechanism should be based on its = effectiveness in accessing services that are IPv6 only. =20 > =20 > WEG> Again, are you or are you not using a relay router? You keep = going back and forth. No, I don't keep going back and forth. I am able to use 6to4 usefully = without a relay router. But I do have the anycast address configured = as the relay router, and I find that useful also. > Bluntly, this isn=92t about whether you, or anyone else at IETF use = 6to4. Nor, bluntly, is it about a few big content providers or whomever else = you want to label as important. The internet is a hugely diverse place, = and you don't get to dismiss the concerns of people whom you want to = label as red herrings. Again, 40-something percent of the IPv6 traffic = that is observed on the net today uses 6to4. That's about as much as = Teredo, it's a hell of a lot more than native v6. As long as 6to4 is = one of the major ways that people get IPv6 connectivity (and it clearly = is), it's premature to declare 6to4 historic. > We are the longest of the long tail; the smallest percentage, the = exception to the rule, not the exception that proves the rule. We=92re = network geeks; we=92re willing to deal with dodgy connectivity or = otherwise fiddly methods of doing things to test them and to prove a = point. This discussion cannot be about whether the protocol should be = preserved because some marginal percentage of folks in IETF use 6to4 = successfully. 40-something percent of the traffic is not marginal. The marginal use = is, currently, of native IPv6. > I am not disagreeing that for some value of =93work=94 6to4 works to = reach IPv6-only things. What I am saying is that the very things you = illustrate here make it only acceptable for testing, and not for any = sort of real substitute for IPv6 connectivity. What user is going to = accept +100ms in latency due to suboptimal relay choice, or waiting = multiple seconds for IPv6 to time out because 6to4 didn=92t work in that = particular network setup? 100ms extra latency as compared to what? Nonexistent v6 service when = they need to use v6? Using v6 for services for which v4 will do just = fine? And in which use cases does that 100ms extra latency apply? = None in the ones I'm seeing today, on IPv6 day. =20 You are the one who keeps citing red herrings as evidence that 6to4 = should be deprecated. You want to take the least compelling use cases = for IPv6, and when 6to4 performs suboptimally for some of those cases, = use that as an excuse to sabotage it. =20 > I think that the evidence says that 6to4 is actually *ineffective* by = the evaluation you suggest =96 a good portion of the time it either = utterly fails or provides such degraded service that it may as well not = work.=20 The evidence is that people are using it. You're trying to subject it = to test cases that are largely meaningless - because in those cases IPv6 = (of any kind) provides no marginal value in the near term. > KM> - Enterprises have applications that need to be able to = communicate with large numbers of hosts spread over a diverse area. = IPv6 is clearly the way that they want to go, but it's not widely = available at present. 6to4 provides them with a means of routing = traffic to their hosts in the interim until widespread support for IPv6 = exists. >=20 > WEG> So do IPv6IP or GRE tunnels. Been using one at home for 3+ years = now. And honestly, if this type of application is going to be = enterprise-class, it needs to be in conjunction with ISP deployment of = IPv6, not in spite of it. Almost all usage of IPv6 today is in spite of ISPs. For that matter, a = great many successful IPv4 applications today are deployed in spite of = ISPs. Again, ISPs in general have let us down, and 6to4 and Teredo are = carrying ~90% of IPv6 traffic. ISPs are not in a good position to = demand that 6to4 be deprecated. =20 > KM> What you're saying is that applications developers shouldn't = bother with actually trying to use IPv6 until the ISPs get their act = together and deploy it. Well guess what? The ISPs have let us down. = We've been waiting for 15 years for the ISPs to roll out IPv6, and for = most of those 15 years they were all telling us that there were no = applications for it. Now the ISPs are scrambling to get IPv6 into their = networks, and they want to sabotage the IPv6 mechanisms that we have in = place even before they are actually offering product. > =20 > WEG> Yes, yes, shame on the big, bad ISPs and their lack of = deployment. Trust me, I=92m as annoyed with the ISPs I=92ve worked for = and been a customer of that it is taking so long to get IPv6 out there = too. > But=856to4 sabotaged itself. This draft is acknowledging reality that = it really didn=92t work the way we=92d hoped. I have no problem with acknowledging the shortcomings of 6to4 and = especially of the use of anycast addresses for relay routers. There = are valuable lessons to be learned there. But face it, a lot of stuff = that's widely deployed on the Internet and useful doesn't work as well = as we hoped. We generally don't try to sabotage things that are useful = to people. > There is no active malevolence here on the part of the ISPs. In fact = many of them (us?) have deployed or will be deploying 6to4 relays to = improve the customer experience until native service is available, and = are supporting the recommendations to make 6to4 suck less in = draft-carpenter. That's excellent news. But the current proposal on the table to = deprecate 6to4 is premature, confusing, and harmful to real users. > KM>Widespread IPv6 support for native IPv6 would be when native IPv6 = is available everywhere that IPv4 access is available, from at least one = provider, with quality (connectivity, reliability, support) = approximately as good as IPv4, and at a reasonable price. In other = words, you can't expect applications to rely on native IPv6 until it's = reliably available everywhere that they need to use it. >=20 > WEG> So Widespread IPv6 has to have reliability and support equivalent = to IPv4, yet you're saying that you can expect applications to rely on = 6to4 in the meantime despite evidence that it's unreliable, and the = virtual guarantee that it won't be supported by the upstream ISP? > =20 > KM>There's no such virtual guarantee. =20 > WEG>I should probably have clarified that by =93support=94 I don=92t = mean =93will pass protocol 41 IPv4 packets.=94 I mean =93can call and = yell at someone when it breaks.=94 Make more sense now? So let's narrow the focus on relay routers that advertise anycast = addresses. I think it's clear that they're the major part of the = problem with 6to4. Maybe there is a way to filter out the = advertisements for the ones that blackhole traffic; maybe all such = advertisements for those prefixes should be filtered and 6to4 users = should have to explicitly configure relay routers. But whatever the = fix, this is a fairly narrow problem and it warrants narrow corrective = action. > WEG> I am simply saying that I do not for a second believe that those = same applications that are so important to that user community are at = the same time unimportant enough that they're the sacrificial lamb that = has to go IPv6-only when the majority of that user community, no matter = how small, doesn't have native IPv6 access yet. > =20 > KM>You have absolutely no idea which applications will be important to = the user community tomorrow. Who knows what will be the next netflix, = twitter, facebook, youtube, ... ? The Internet is successful not = because it supports some small number of apps that operators think are a = good idea; it's successful because it (at least as originally = architected) can support a wide range of apps without operators having = to bless them.=20 > WEG> One of the few places I=92m in agreement with you. However, it=92s = not a justification for 6to4. It=92s a justification for ubiquitous = IPv6. It's not one versus the other. 6to4 is helping to promote ubiquitous = IPv6. > It=92s not about whether the operators =93bless=94 an application or = not. If those up-and-coming applications are saddled with the = performance hit that 6to4 represents, they are unlikely to be = successful. In other words, 6to4 will not move the needle on innovative = IPv6-only applications, so they=92re tied to the native IPv6 rollout = schedule. Sad, but true. There are many applications that can't be widely successful because of = NATs, or lack of addresses. IPv6 (and 6to4) offer those applications a = chance to be successful. 6to4 does not inherently represent a = performance hit. In some cases, it provides connectivity to other IPv6 = hosts (whether 6to4 or native) where no other connectivity was as easily = available (and without having to explicitly set up tunnels that also = cause performance hits.) Some connectivity to IPv6 is generally better = than none. Again, if you try to compare v6 performance to v4 = performance, it will be a long time until there are no cases where the = v6 performance comes up short. Those comparisons are meaningless, = because the reason to move to 6to4 isn't to get better performance than = v6 for applications that already work fine with v4. It's to enable new = kinds of apps that don't work well in a v4 network full of NATs, and to = enable new users and new kinds of devices to be able to fully = participate in the Internet. > =20 > WEG>This is the essence of the IPv6 content vs access chicken/egg = problem, and 6to4 absolutely will not break the impasse. 6to4 breakage = is the most common thing that content providers cite as reasons why they = don't just go dual-stack. Why would an enterprise application be any = different? > =20 > KM> It doesn't really matter much whether "content-providers" (as in = web site providers) go "dual stack" now. Sure, they need to be gearing = up for it, making sure that they understand it, making sure that their = networks support it. (Or maybe they'll just install v6-to-v4 proxies at = their borders so that they can keep providing good customer service in = the face of LSN-induced brain damage on the public v4 network.) But = assuming their applications work through LSN, they're going to keep = supporting v4 for a long time anyway, because that's the established = base of interoperability for their products and services. Existing = "content providers" are not going to drive adoption of IPv6. They're = going to follow it. Web and email will be the last applications to = migrate. New content might appear on v6, and that might drive adoption. = But to the extent that it drives adoption, it probably won't be from = the currently established players that already have plenty of v4 = addresses and infrastructure. It will be from new things that take = advantage of the niches created by IPv6 that didn't exist before. > WEG> This is a variant of the old =93IPv6 Killer App=94 discussion. = We=92re still waiting for one, largely because people are afraid of = excluding some non-trivial percentage of the populace from being able to = use their new, cool thing because it=92s IPv6-only, and they don=92t = think it will so compelling as to be a justification for people to find = a workaround or clamor for IPv6 support. Though I have no doubt that some such apps will eventually appear, the = case for IPv6 doesn't have to be a single killer app that's visible to = everybody. The Internet isn't only valuable because of killer apps. = B2b communication (e.g. EDI), for instance, isn't any single kind of = killer app that people generally recognize. But it's extremely valuable = to society, and it's tremendously impaired by NATs and widespread use of = private IPv4 address space. > IMO, IPv4 exhaustion and CGN is the closest thing we have to a Killer = App for IPv6. If 6to4 somehow provides an incentive for folks to = generate IPv6-only applications, and for ordinary users to start using = 6to4 to connect to IPv6, I=92m wondering why it hasn=92t accomplished = that goal in the last 10 years?What would be different all of the = sudden?=20 Killer apps are in the eyes of the beholders. Early adopters of IPv6 = are using it in myriad ways that are quite useful to them. If they can = find uses for v6, so can new users, and makers of new products. It's = not necessary for there to be a single killer app that requires v6 that = everyone knows about, for IPv6 to be widely useful. > KM> 6to4 is as reliable as IPv4 is, if it isn't asked to cross a relay = router. > WEG> perhaps (with the exception of MTU issues that plague any = tunneled protocol), but you continue to not provide any examples of this = being used anywhere, in the face of significant evidence that 6to4 is = horribly unreliable *with* a relay. So this gets filed in the same place = as my 100% secure file server which happens to be unplugged from power = and network and encased in 10ft of concrete. Theoretically perfect, but = otherwise practically useless. > =20 > KM>What is "anywhere" to you? You seem to have a content-centric view = of the Internet. I do not. Meanwhile, you persist in saying that = something that I've used regularly for more than 10 years, to do useful = work, isn't being used anywhere. > WEG> No, I=92m trying to follow the same distinction you=92ve drawn = between 6to4 with relays and without and understand how that=92s being = used, since apparently 6to4 without relays is a lot less problematic and = you=92ve had such success with it. What I=92ve read is multiple people = trying to explain to you that non-anycast 6to4 (3056) is not being used, = and you continuing to insist that it=92s heavily used by providing = examples of 3068. Sorry, that's a complete mischaracterization of everything I have said. = =20 > KM> I keep seeing figures that 6to4 comprises 40-some-odd percent of = IPv6 traffic, while native IPv6 is around 10 percent. By your logic, = native v6 should be deprecated because it doesn't work reliably and it's = not being used anywhere. > WEG> While my general view is that 40% of less than 1% of Internet = traffic amounts to a statistical anomaly, citation, please? Assuming = that the source of your statistic is able to distinguish between types = of protocol 41 traffic, that 40% is almost definitely traffic that is = using a relay, BTW. You are as capable of using google as I am. And the sources I found = didn't break the 6to4 traffic down between 6to4-to-6to4 vs. = 6to4-to-native (that would definitely have been useful), but your BTW is = pure speculation. My speculation would be the opposite, but that's just = based on my personal experience with 6to4. =20 (actually it would be nice for such stats to get a full breakdown of the = different cases: native to native, native to 6to4, native to Teredo, = 6to4 to Teredo, 6to4 to 6to4, Teredo to Teredo) =20 > KM> The disease is the current IPv4 network with NATs and LSNs and a = paucity of address space. 6to4 is like a drug that can let some = valuable v6 applications grow (even if a bit stunted) and survive until = there's once again a network that will support them. Sure, there are = some side effects and contraindications. But it's useful when used with = awareness of its limitations. You're arguing that it should be = discouraged because it causes some problems. Indeed it does. But LSN = also causes problems, and is a bigger dead-end than 6to4, and it's full = steam ahead with that. At least 6to4 is designed to ease transition to = a saner world, which is a lot more than I can say for LSN. > WEG> LSN is a necessary evil brought on by the lack of ubiquitous IPv6 = support, which has many causes. I don=92t like it either. The thing you = are failing to realize is that IETF saying that 6to4 use is a bad idea = in no way stops consenting adults from using it in spite of the side = effects and contraindications, but it does put a much finer point on = those contraindications. People who are using 6to4 now might need for new implementations of = hardware and operating systems to support it. This draft explicitly = discourages that. =20 On a broader level, people have a hard time grasping what it means to = 'deprecate' something or to declare it Historic even if the document = goes into a fair amount of detail about it. They tend to get the = high-order bit and to misinterpret that. =20 > KM> I have no doubt that many of those "major content providers" are = correct when they don't see 6to4 as an acceptable substitute for them. = But the Internet doesn't exist just to support "major content = providers". So stop trying to sabotage something that works well enough = for other users. > WEG> Not trying to imply that it does. I=92m saying that your = definition of =93works well enough=94 and the average user=92s are = widely different, making 6to4 a no-op for the average user. The content = providers=92 position on end users trying to use 6to4 to reach their = content is an example of that point.=20 The average user of what? Of IPv6 apps? I don't think content = providers know squat about the average users of IPv6 apps. And anything = that compares 6to4 performance to IPv4 performance is a red herring, at = least as applied to an argument about whether 6to4 or not is justified. =20= > WEG> Why are we having a World IPv6 Day? In part to shake loose the = broken 6to4 users that may not even know that 6to4 is enabled/broken so = that content providers can be more confident that they can dual-stack = their websites without risk of significant user impact due to breakage. > =20 > KM> I'm looking forward to World IPv6 Day, and what will be learned = from it. But again, how well 6to4 works with "major content providers" = is irrelevant. > WEG> I might argue that this is because 6to4 is largely irrelevant and = will become increasingly more so as major ISPs roll out IPv6 in the next = 12-18 months. This is about removing barriers to deployment and use of = IPv6 for the increasing population of Native IPv6 users, not trying to = buff the turd for a tiny (but unfortunately very vocal) minority.=20 I'll be happy to abandon use of 6to4 when I can get native (and = non-NATted) IPv6 access anywhere I live, anywhere I work, and anywhere I = travel. If that happens in the next 12-18 months I'll be ecstatic. = But I'm not holding my breath. In 12-18 months I'll be lucky if I can = get native v6 access in one of those cases. For the others, I'll = continue to need some kind of tunneling solution, and 6to4 is often the = one that works best. Deprecating 6to4 is imposing a barrier to = deployment, not removing one. > WEG>Finally, we're having problems with equipment that doesn't support = IPv6 at all. 6to4 is not high on the priority list to implement compared = with a functional IPv6 stack, meaning that on new gear, it likely won't = get implemented until it's no longer necessary. > =20 > KM> Gear that doesn't support IPv6 by now is pretty odd gear. But = I'm not going to tell you not to use it. I'm just saying, if you want = odd gear to work for you in your own specific use cases, don't try to = sabotage other odd things that work for other people in their specific = use cases. > WEG> No. As have multiple others, you assume that I am talking about = the usual suspects in core routing and enterprise-class networking and = servers. Where did you get that idea? > The consumer electronics space is WOEFULLY behind by comparison. = That=92s not =93odd=94 gear. If I were to apply your criteria about what justifies use of 6to4 to = such devices, they would be odd gear. > And this isn=92t about me (for some value of me) wanting that gear to = work for some corner case application. This is about me having to = support millions of customers who want that gear to work because they = don=92t want to buy replacements for something that they see as working = just fine today. See also CGN =3D necessary evil. Yes, it's an important problem. Good luck trying to solve it while = you're sabotaging things that work for other people. Keith --Apple-Mail-21-692146429 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
From: Keith Moore = [mailto:moore@network-heretics.com] 
Sent: Tuesday, June 07, 2011 6:48 = PM
To: George,= Wesley
Cc: ietf@ietf.org; v6ops@ietf.org
Subject: Re: [v6ops] Last Call: = <draft-ietf-v6ops-6to4-to-historic-04.txt> (Request to move = Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to = Informational RFC
KM>I've = been using 6to4 on a regular, often daily, basis since the late 1990s. =   6to4 has allowed me to develop IPv6 applications and test them on = real networks, and deploy them in limited circumstances.  6to4 has = also allowed me to remotely access computers on my SOHO networks, using = any application protocol that I chose to do so, with out-of-the-box = hardware and software, without any application-specific proxies, and = generally without any application-specific configuration.  None of = these scenarios required a relay router.  All of them were, and = continue to be, useful.
 
KM> Yes, I've = experienced on many occasions that using 6to4 to access dual-stack web = servers doesn't always work so well.  Sometimes it picks a = suboptimal path because the relay router isn't convenient. =  Sometimes the v6 path doesn't work at all and the application has = to time out and retry using v4.   But this never really bothered me = much, because my = purpose in using 6to4 wasn't to try to access services that I could get = to via IPv4 anyway.  And neither, I suggest, is that a = reasonable metric for evaluating 6to4 or any other IPv6 transition = mechanism.   The metric for evaluating an IPv6 transition mechanism = should be based on its effectiveness in accessing services that are IPv6 = only.   
Bluntly, = this isn=92t about whether you, or anyone else at IETF use 6to4. =

No= r, bluntly, is it about a few big content providers or whomever else you = want to label as important.  The internet is a hugely diverse = place, and you don't get to dismiss the concerns of people whom you want = to label as red herrings.   Again, 40-something percent of the IPv6 = traffic that is observed on the net today uses 6to4.  That's about = as much as Teredo, it's a hell of a lot more than native v6.  As = long as 6to4 is one of the major ways that people get IPv6 connectivity = (and it clearly is), it's premature to declare 6to4 = historic.

We are the = longest of the long tail; the smallest percentage, the exception to the = rule, not the exception that proves the rule. We=92re network geeks; = we=92re willing to deal with dodgy connectivity or otherwise fiddly = methods of doing things to test them and to prove a point. This = discussion cannot be about whether the protocol should be preserved = because some marginal percentage of folks in IETF use 6to4 = successfully.

40-something percent of the traffic is not marginal. =  The marginal use is, currently, of native = IPv6.

I am not = disagreeing that for some value of =93work=94 6to4 works to reach = IPv6-only things. What I am saying is that the very things you = illustrate here make it only acceptable for testing, and not for any = sort of real substitute for IPv6 connectivity. What user is going to = accept +100ms in latency due to suboptimal relay choice, or waiting = multiple seconds for IPv6 to time out because 6to4 didn=92t work in that = particular network setup? =

100ms extra latency as compared to what?  Nonexistent v6 service = when they need to use v6?   Using v6 for services for which v4 will = do just fine?   And in which use cases does that 100ms extra = latency apply?  None in the ones I'm seeing today, on IPv6 day. =   

You are the one who keeps citing = red herrings as evidence that 6to4 should be deprecated.  You want = to take the least compelling use cases for IPv6, and when 6to4 performs = suboptimally for some of those cases, use that as an excuse to sabotage = it.  

I think = that the evidence says that 6to4 is actually *ineffective* by the = evaluation you suggest =96 a good portion of the time it either utterly = fails or provides such degraded service that it may as well not = work. 
=

The evidence is that = people are using it.  You're trying to subject it to test cases = that are largely meaningless - because in those cases IPv6 (of any kind) = provides no marginal value in the near term.

KM> - = Enterprises have applications that need to be able to communicate with = large numbers of hosts spread over a diverse area.  IPv6 is clearly = the way that they want to go, but it's not widely available at present. =  6to4 provides them with a means of routing traffic to their hosts = in the interim until widespread support for IPv6 exists.

WEG> = So do IPv6IP or GRE tunnels. Been using one at home for 3+ years now. = And honestly, if this type of application is going to be = enterprise-class, it needs to be in conjunction with ISP deployment of = IPv6, not in spite of = it.

Almost= all usage of IPv6 today is in spite of ISPs.   For that matter, a = great many successful IPv4 applications today are deployed in spite of = ISPs.  Again, ISPs in general have let us down, and 6to4 and Teredo = are carrying ~90% of IPv6 traffic.   ISPs are not in a good = position to demand that 6to4 be deprecated. =  

KM> What you're saying = is that applications developers shouldn't bother with actually trying to = use IPv6 until the ISPs get their act together and deploy it.  Well = guess what?  The ISPs have let us down.  We've been waiting = for 15 years for the ISPs to roll out IPv6, and for most of those 15 = years they were all telling us that there were no applications for it. =  Now the ISPs are scrambling to get IPv6 into their networks, and = they want to sabotage the IPv6 mechanisms that we have in place even = before they are actually offering product.
But=856to4 = sabotaged itself. This draft is acknowledging reality that it really = didn=92t work the way we=92d hoped. =

I = have no problem with acknowledging the shortcomings of 6to4 and = especially of the use of anycast addresses for relay routers.   = There are valuable lessons to be learned there.  But face it, a lot = of stuff that's widely deployed on the Internet and useful doesn't work = as well as we hoped.  We generally don't try to sabotage things = that are useful to people.

There is no = active malevolence here on the part of the ISPs. In fact many of them = (us?) have deployed or will be deploying 6to4 relays to improve the = customer experience until native service is available, and are = supporting the recommendations to make 6to4 suck less in = draft-carpenter.
<= div>
That's excellent news.  But the current proposal on = the table to deprecate 6to4 is premature, confusing, and harmful to real = users.

KM>There's no such virtual guarantee. =   
WEG> I am simply saying = that I do not for a second believe that those same applications that are = so important to that user community are at the same time unimportant = enough that they're the sacrificial lamb that has to go IPv6-only when = the majority of that user community, no matter how small, doesn't have = native IPv6 access yet.
 
KM>You have absolutely no = idea which applications will be important to the user community = tomorrow.   Who knows what will be the next netflix, twitter, = facebook, youtube, ... ?   The Internet is successful not because = it supports some small number of apps that operators think are a good = idea; it's successful because it (at least as originally architected) = can support a wide range of apps without operators having to bless = them. 
WEG> One = of the few places I=92m in agreement with you. However, it=92s not a = justification for 6to4. It=92s a justification for ubiquitous IPv6. =

It= 's not one versus the other.   6to4 is helping to promote = ubiquitous IPv6.

It=92s not = about whether the operators =93bless=94 an application or not. If those = up-and-coming applications are saddled with the performance hit that = 6to4 represents, they are unlikely to be successful. In other words, = 6to4 will not move the needle on innovative IPv6-only applications, so = they=92re tied to the native IPv6 rollout schedule. Sad, but = true.

There are many applications that can't be widely successful because = of NATs, or lack of addresses.  IPv6 (and 6to4) offer those = applications a chance to be successful.   6to4 does not inherently = represent a performance hit.  In some cases, it provides = connectivity to other IPv6 hosts (whether 6to4 or native) where no other = connectivity was as easily available (and without having to explicitly = set up tunnels that also cause performance hits.)   Some = connectivity to IPv6 is generally better than none.   Again, if you = try to compare v6 performance to v4 performance, it will be a long time = until there are no cases where the v6 performance comes up short.   = Those comparisons are meaningless, because the reason to move to 6to4 = isn't to get better performance than v6 for applications that already = work fine with v4.  It's to enable new kinds of apps that don't = work well in a v4 network full of NATs, and to enable new users and new = kinds of devices to be able to fully participate in the = Internet.

WEG>This is the essence of the IPv6 = content vs access chicken/egg problem, and 6to4 absolutely will not = break the impasse. 6to4 breakage is the most common thing that content = providers cite as reasons why they don't just go dual-stack. Why would = an enterprise application be any = different?
KM> It doesn't really = matter much whether "content-providers" (as in web site providers) go = "dual stack" now.  Sure, they need to be gearing up for it, making = sure that they understand it, making sure that their networks support = it.  (Or maybe they'll just install v6-to-v4 proxies at their = borders so that they can keep providing good customer service in the = face of LSN-induced brain damage on the public v4 network.)   But = assuming their applications work through LSN, they're going to keep = supporting v4 for a long time anyway, because that's the established = base of interoperability for their products and services.   = Existing "content providers" are not going to drive adoption of IPv6. =   They're going to follow it.  Web and email will be the last = applications to migrate.  New content might appear on v6, and that = might drive adoption.  But to the extent that it drives adoption, = it probably won't be from the currently established players that already = have plenty of v4 addresses and infrastructure.  It will be from = new things that take advantage of the niches created by IPv6 that didn't = exist before.
IMO, IPv4 exhaustion and = CGN is the closest thing we have to a Killer App for IPv6. If 6to4 = somehow provides an incentive for folks to generate IPv6-only = applications, and for ordinary users to start using 6to4 to connect to = IPv6, I=92m wondering why it hasn=92t accomplished that goal in the last = 10 years?What would be different all of the sudden? 

Killer apps are in the eyes of the = beholders.  Early adopters of IPv6 are using it in myriad ways that = are quite useful to them.   If they can find uses for v6, so can = new users, and makers of new products.    It's not necessary = for there to be a single killer app that requires v6 that everyone knows = about, for IPv6 to be widely useful.

KM> 6to4 is as reliable as = IPv4 is, if it isn't asked to cross a relay router.
WEG> perhaps = (with the exception of MTU issues that plague any tunneled protocol), = but you continue to not provide any examples of this being used = anywhere, in the face of significant evidence that 6to4 is horribly = unreliable *with* a relay. So this gets filed in the same place as my = 100% secure file server which happens to be unplugged from power and = network and encased in 10ft of concrete. Theoretically perfect, but = otherwise practically useless.
 
KM>What is "anywhere" to = you?  You seem to have a content-centric view of the Internet. =  I do not.   Meanwhile, you persist in saying that something = that I've used regularly for more than 10 years, to do useful work, = isn't being used anywhere.WEG> No, = I=92m trying to follow the same distinction you=92ve drawn between 6to4 = with relays and without and understand how that=92s being used, since = apparently 6to4 without relays is a lot less problematic and you=92ve = had such success with it. What I=92ve read is multiple people trying to = explain to you that non-anycast 6to4 (3056) is not being used, and you = continuing to insist that it=92s heavily used by providing examples of = 3068.

Sorry, that's a complete mischaracterization of everything I have = said.    

KM>  I keep seeing figures that 6to4 = comprises 40-some-odd percent of IPv6 traffic, while native IPv6 is = around 10 percent.  By your logic, native v6 should be deprecated = because it doesn't work reliably and it's not being used = anywhere.
WEG> = While my general view is that 40% of less than 1% of Internet traffic = amounts to a statistical anomaly, citation, please? Assuming that the = source of your statistic is able to distinguish between types of = protocol 41 traffic, that 40% is almost definitely traffic that is using = a relay, = BTW.

You are as capable of using google as I am.    And the = sources I found didn't break the 6to4 traffic down between 6to4-to-6to4 = vs. 6to4-to-native (that would definitely have been useful), but your = BTW is pure speculation.  My speculation would be the opposite, but = that's just based on my personal experience with 6to4. =   

(actually it would be nice for = such stats to get a full breakdown of the different cases: native to = native, native to 6to4, native to Teredo, 6to4 to Teredo, 6to4 to 6to4, = Teredo to Teredo)
 The = disease is the current IPv4 network with NATs and LSNs and a paucity of = address space.  6to4 is like a drug that can let some valuable v6 = applications grow (even if a bit stunted) and survive until there's once = again a network that will support them.  Sure, there are some side = effects and contraindications.  But it's useful when used with = awareness of its limitations.  You're arguing that it should be = discouraged because it causes some problems.  Indeed it does. =  But LSN also causes problems, and is a bigger dead-end than 6to4, = and it's full steam ahead with that.  At least 6to4 is designed to = ease transition to a saner world, which is a lot more than I can say for = LSN.
WEG> LSN is a = necessary evil brought on by the lack of ubiquitous IPv6 support, which = has many causes. I don=92t like it either. The thing you are failing to = realize is that IETF saying that 6to4 use is a bad idea in no way stops = consenting adults from using it in spite of the side effects and = contraindications, but it does put a much finer point on those = contraindications.
<= div>
People who are using 6to4 now might need for new = implementations of hardware and operating systems to support it. =  This draft explicitly discourages that. =  

On a broader level, people have a hard = time grasping what it means to 'deprecate' something or to declare it = Historic even if the document goes into a fair amount of detail about = it.  They tend to get the high-order bit and to misinterpret that. =  

KM> I have no doubt that = many of those "major content providers" are correct when they don't see = 6to4 as an acceptable substitute for them.  But the Internet = doesn't exist just to support "major content providers".  So stop = trying to sabotage something that works well enough for other = users.
WEG> Not trying to imply that it does. I=92m = saying that your definition of =93works well enough=94 and the average = user=92s are widely different, making 6to4 a no-op for the average user. = The content providers=92 position on end users trying to use 6to4 to = reach their content is an example of that point. 
=

The average user of what? =   Of IPv6 apps?  I don't think content providers know squat = about the average users of IPv6 apps.  And anything that compares = 6to4 performance to IPv4 performance is a red herring, at least as = applied to an argument about whether 6to4 or not is justified. =  

WEG> Why are we having a = World IPv6 Day? In part to shake loose the broken 6to4 users that may = not even know that 6to4 is enabled/broken so that content providers can = be more confident that they can dual-stack their websites without risk = of significant user impact due to = breakage.
KM> I'm looking forward = to World IPv6 Day, and what will be learned from it.   But again, = how well 6to4 works with "major content providers" is = irrelevant.
WEG> I = might argue that this is because 6to4 is largely irrelevant and will = become increasingly more so as major ISPs roll out IPv6 in the next = 12-18 months. This is about removing barriers to deployment and use of = IPv6 for the increasing population of Native IPv6 users, not trying to = buff the turd for a tiny (but unfortunately very vocal) minority. 
=

I'll be happy to abandon = use of 6to4 when I can get native (and non-NATted) IPv6 access anywhere = I live, anywhere I work, and anywhere I travel.  If that happens in = the next 12-18 months I'll be ecstatic.   But I'm not holding my = breath.  In 12-18 months I'll be lucky if I can get native v6 = access in one of those cases.  For the others, I'll continue to = need some kind of tunneling solution, and 6to4 is often the one that = works best.   Deprecating 6to4 is imposing a barrier to deployment, = not removing one.

WEG>Finally, we're having problems with = equipment that doesn't support IPv6 at all. 6to4 is not high on the = priority list to implement compared with a functional IPv6 stack, = meaning that on new gear, it likely won't get implemented until it's no = longer necessary.
KM> Gear that doesn't = support IPv6 by now is pretty odd gear.     But I'm not going = to tell you not to use it.  I'm just saying, if you want odd gear = to work for you in your own specific use cases, don't try to sabotage = other odd things that work for other people in their specific use = cases.
WEG> No. As have = multiple others, you assume that I am talking about the usual suspects = in core routing and enterprise-class networking and servers. =

Whe= re did you get that idea?

The consumer electronics = space is WOEFULLY behind by comparison. That=92s not =93odd=94 gear. =

If = I were to apply your criteria about what justifies use of 6to4 to such = devices, they would be odd gear.

And this isn=92t about = me (for some value of me) wanting that gear to work for some corner case = application. This is  about me having to support millions of = customers who want that gear to work because they don=92t want to buy = replacements for something that they see as working just fine today. See = also CGN =3D necessary = evil.

Yes, it's an important problem.     Good luck trying = to solve it while you're sabotaging things that work for other = people.

Keith


= --Apple-Mail-21-692146429-- From mrex@sap.com Wed Jun 8 13:37:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429DE11E8104; Wed, 8 Jun 2011 13:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.108 X-Spam-Level: X-Spam-Status: No, score=-9.108 tagged_above=-999 required=5 tests=[AWL=1.141, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH5hss9NPbnM; Wed, 8 Jun 2011 13:37:09 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5155B11E8107; Wed, 8 Jun 2011 13:37:09 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p58Kb7jB028099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Jun 2011 22:37:07 +0200 (MEST) From: Martin Rex Message-Id: <201106082037.p58Kb7g5008839@fs4113.wdf.sap.corp> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 8 Jun 2011 22:37:07 +0200 (MEST) In-Reply-To: <20110608160415.1F8CF18C121@mercury.lcs.mit.edu> from "Noel Chiappa" at Jun 8, 11 12:04:15 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: v6ops@ietf.org, ietf@ietf.org, jnc@mercury.lcs.mit.edu Subject: Re: [v6ops] Last Call: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 20:37:10 -0000 Noel Chiappa wrote: > > > From: Martin Rex > > > > Classification of 6to4 as historic is [in]appropriate use of the IETF > > process, because it would be a political .. statement. > > Well, we've never done _that_ before, have we? Wouldn't want to set an > unfortunate precedent. I'm much more worried about the important part that you didn't quote, that moving 6to4 to historic is a technically inaccurate statement. How about downgrading it (rfc3056+rfc3068, I assume) from "Proposed" to "Experimental", acknowledging the fact that "consumers" will likely have to set it up themselves, it is rarely going to work out of the box and might not be available in all implementations. -Martin From internet-drafts@ietf.org Wed Jun 8 13:55:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D55521F8443; Wed, 8 Jun 2011 13:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoQzRBi4JE4u; Wed, 8 Jun 2011 13:55:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1B321F844B; Wed, 8 Jun 2011 13:54:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110608205455.21806.92145.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2011 13:54:55 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 20:55:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : IPv6 AAAA DNS Whitelisting Implications Author(s) : Jason Livingood Filename : draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06.txt Pages : 36 Date : 2011-06-08 This document describes the practice and implications of whitelisting DNS recursive resolvers in order to limit AAAA resource record responses (which contain IPv6 addresses) sent by authoritative DNS servers. This is an IPv6 transition mechanism used by domains as a method for incrementally transitioning inbound traffic to a domain from IPv4 to IPv6 transport. The audience for this document is the Internet community generally, particularly IPv6 implementers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-i= mplications-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-im= plications-06.txt From joelja@bogus.com Wed Jun 8 14:22:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C1B1F0C55 for ; Wed, 8 Jun 2011 14:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.93 X-Spam-Level: X-Spam-Status: No, score=-100.93 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5T0+YEdGH-Z for ; Wed, 8 Jun 2011 14:22:36 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 65EE71F0C51 for ; Wed, 8 Jun 2011 14:22:34 -0700 (PDT) Received: from [192.168.1.170] (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 p58LMIio065623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Jun 2011 21:22:31 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <8E93014B-E0BC-4001-95F4-D97917CFF2F6@cisco.com> Date: Wed, 8 Jun 2011 02:33:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DED7A3D.1060008@viagenie.ca> <8E93014B-E0BC-4001-95F4-D97917CFF2F6@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 08 Jun 2011 21:22:32 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] Call for agenda items X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 21:22:37 -0000 Requesting more than 5 hours I think runs the risk of us overstating our = value to the organization. So we need to be judicious with our time and consider how and where = reporting on the event (or preparation for it) advances our charter = goals and furthers work being done or under consideration. On Jun 7, 2011, at 9:41 AM, Fred Baker wrote: >=20 > On Jun 6, 2011, at 6:09 PM, Marc Blanchet wrote: >=20 >> to me, we should reserve significant time for many findings that = would follow June 8th. This is the best data points we could have for = v6ops charter. Therefore, I would suggest to chair to request as much = slot time as possible. >=20 > Agreed that a post mortem (er, how do you say "after birth" or "after = a coming our party" in Latin?) is an important discussion to have. >=20 > I have more or less done that. I routinely request a 2.5 hour slot and = a 2 hour slot, and last November requested two 2.5 hour slots (which we = didn't get, but we were placed on Friday afternoon and told that we had = explicit permission to run overtime). I have requested 4.5 hours this = time as well. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From joelja@bogus.com Wed Jun 8 14:23:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAF011E8142; Wed, 8 Jun 2011 14:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.23 X-Spam-Level: X-Spam-Status: No, score=-101.23 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFo3RvPDcrlC; Wed, 8 Jun 2011 14:23:14 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3581D11E8076; Wed, 8 Jun 2011 14:23:13 -0700 (PDT) Received: from [192.168.1.170] (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 p58LMIip065623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Jun 2011 21:22:32 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4-654742651 From: Joel Jaeggli In-Reply-To: Date: Wed, 8 Jun 2011 02:55:40 -0700 Message-Id: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <4A7A2E91-F290-4DBE-88D0-965443DCECBB@ecs.soton.ac.uk> <20110607063336.GO45955@Space.Net> To: trejrco@gmail.com X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 08 Jun 2011 21:22:34 +0000 (UTC) Cc: "v6ops@ietf.org WG" , ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 21:23:15 -0000 --Apple-Mail-4-654742651 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 7, 2011, at 4:33 AM, TJ wrote: >=20 > > Less than 1% of the IPv6 traffic reaching us is 6to4. >=20 > Unless you provide IPv6 only sites, you should see very little ... = that is part of the point :). >=20 > >=20 > > It's time to remove the stabilisers on the IPv6 bicycle. >=20 > I agree, but get me native everywhere before taking away one = connection mechanism that does work. >=20 That fails, 20% of time. Seems unlikely that it's going to go away = anytime soon, draft or no, that said it seems unwise to keep telling the = users and implementors to use it. by default. =20 > Just my $.02, > /TJ ... ready for world IPv6 Day?=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --Apple-Mail-4-654742651 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jun 7, 2011, at 4:33 AM, TJ wrote:


> Less than 1% of the IPv6 traffic reaching us is 6to4.

Unless you provide IPv6 only sites, you should see very little ... that is part of the point :).

<snip>

> It's time to remove the stabilisers on the IPv6 bicycle.

I agree, but get me native everywhere before taking away one connection mechanism that does work.

That fails, 20% of time. Seems unlikely that it's going to go away anytime soon, draft or no, that said it seems unwise to keep telling the users and implementors to use it. by default.  

Just my $.02,
/TJ ... ready for world IPv6 Day?

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

--Apple-Mail-4-654742651-- From Dmitry.Anipko@microsoft.com Wed Jun 8 14:32:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A7411E80A6; Wed, 8 Jun 2011 14:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZaHoyzB3Sw6; Wed, 8 Jun 2011 14:32:32 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id D425D11E807A; Wed, 8 Jun 2011 14:32:32 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 8 Jun 2011 14:32:32 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 8 Jun 2011 14:32:31 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.201]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Wed, 8 Jun 2011 14:32:13 -0700 From: Dmitry Anipko To: "v6ops@ietf.org" , "ietf@ietf.org" Date: Wed, 8 Jun 2011 14:32:11 -0700 Thread-Topic: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC Thread-Index: AcwlZVYxaNvHyapZTMGrNtFQ33ZycwAurqpQ Message-ID: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> In-Reply-To: <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.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 Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 21:32:33 -0000 I don't intend to re-spin the discussion that took place in the WG, but I'd= like to say I do agree with the concerns raised in the LC threads by Keith= and others.=20 If there are 6to4 connectivity issues for some 6to4 clients, in my opinion,= those issues would be sufficiently mitigated by RFC 3484/bis. Specifically= , by changing priority of 6to4-to-6to4 below IPv4 (the 6to4->native IPv6 is= already placed below IPv4 by most or all existing implementations of 3484)= . Once priority is changed, 6to4 basically would only be used when it is the = only channel that could work to reach a particular destination. Which means= that it could provide connectivity, when there would be no connectivity if= 6to4 were removed.=20 When native IPv6 is made widely available to users, they just would stop us= ing 6to4. So, I don't understand concerns regarding "evolutionary future of= 6to4". And it unclear to me why IETF would want to take away a _transition= _ technique from people for whom it is working or why there is a need to ta= ke any action beyond the recommendations along the lines of RFC 3484/bis.=20 From tjc@ecs.soton.ac.uk Wed Jun 8 16:05:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF1821F84A2; Wed, 8 Jun 2011 16:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.401 X-Spam-Level: ** X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7+olH0vNlTZ; Wed, 8 Jun 2011 16:05:22 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 1303621F847A; Wed, 8 Jun 2011 16:05:20 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p58N5FQe017014; Thu, 9 Jun 2011 00:05:15 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p58N5FQe017014 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1307574316; bh=lQJKGXrkyHamtz5HFRjxyMfHwms=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=2rg2ZA6mj0fB+bdafqmderRsxhUq0xITFsSzTDhD16Y5ql8gGm4/dDRKp0OqPjD3E k0KJpIjB8CM5gHaUiSZszVBRX91E9x0XPPwjblfXRcz3K+wGFOCGIsZtjfaYdZobA2 xXJO/2nFTRNvlA82dQac9+pcJ33bhcN1YC1d4lag= 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 n5805F0035658597Yr ret-id none; Thu, 09 Jun 2011 00:05:15 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p58N58lN013616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jun 2011 00:05:09 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Tim Chown In-Reply-To: Date: Thu, 9 Jun 2011 00:05:08 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB0690A2B5@PRVPEXVS04.corp.twcable.com> <24F8A8B2-3AA7-47F4-9AC3-52CCF5C8DF34@ecs.soton.ac.uk> To: "v6ops@ietf.org WG" , ietf@ietf.org X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n5805F003565859700; tid=n5805F0035658597Yr; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p58N5FQe017014 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 23:05:23 -0000 On 8 Jun 2011, at 21:19, Keith Moore wrote: >=20 > Nor, bluntly, is it about a few big content providers or whomever else = you want to label as important. The internet is a hugely diverse place, = and you don't get to dismiss the concerns of people whom you want to = label as red herrings. Again, 40-something percent of the IPv6 traffic = that is observed on the net today uses 6to4. That's about as much as = Teredo, it's a hell of a lot more than native v6. As long as 6to4 is = one of the major ways that people get IPv6 connectivity (and it clearly = is), it's premature to declare 6to4 historic. You see 40% of your IPv6 traffic as 6to4, we see rather less than 1%. = Our observation point is as a university on an academic/research network = that is native dual-stack. We probably have most of our IPv6 traffic = come from other universities around the world, who are also most likely = natively connected. Hence little if any need for transition methods. = This may be different to your scenario, of course, but it is hopefully a = future that will be more widespread in time. We did use 6to4 in its router-to-router, site-to-site flavour many years = ago while a project called 6NET ran, but have had no use case for it = since. Perhaps it would be useful to see your use cases more clearly = documented with examples. > Almost all usage of IPv6 today is in spite of ISPs. For that matter, = a great many successful IPv4 applications today are deployed in spite of = ISPs. Again, ISPs in general have let us down, and 6to4 and Teredo are = carrying ~90% of IPv6 traffic. ISPs are not in a good position to = demand that 6to4 be deprecated. =20 We see even less Teredo, i.e. the sum of the 6to4 and Teredo we see is = under 1% of our total IPv6 traffic. I don't know where you see 90%; I = assume it's an environment with home-to-home networks, with no broker or = IPv6 VPN use? > That's excellent news. But the current proposal on the table to = deprecate 6to4 is premature, confusing, and harmful to real users. The problem is that 6to4 is unfortunately also harmful to real users, at = least the ones that don't want to know about IPv6. It will continue to = be until we can be confident no vendor anywhere has 6to4 on by default, = won't it? The question is whether Historic stops knowledgeable people like you = using 6to4 safely in your own context/community, without affecting = 'normal' users. Does it mean 6to4 off be default, or 6to4 removed from = product? > It's not one versus the other. 6to4 is helping to promote ubiquitous = IPv6. The other view is that 6to4 is delaying ubiquitous IPv6 deployment, by = adding brokenness. Geoff's stats illustrate that very well, though those = are not based on vanilla 6to4. Tim From jhw@apple.com Wed Jun 8 16:21:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BD411E808D; Wed, 8 Jun 2011 16:21:53 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKO9W5+DGQsv; Wed, 8 Jun 2011 16:21:53 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3E411E8087; Wed, 8 Jun 2011 16:21:52 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LMH007GSVDWUBY0@mail-out.apple.com>; Wed, 08 Jun 2011 16:20:44 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-75-4df003cc0d09 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 21.FB.29082.CC300FD4; Wed, 08 Jun 2011 16:20:44 -0700 (PDT) Received: from event-10-2-63-213.venue.apple.com (unknown [192.42.249.191]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LMH00J8MVIKRQA0@cardamom.apple.com>; Wed, 08 Jun 2011 16:20:44 -0700 (PDT) From: james woodyatt In-reply-to: Date: Wed, 08 Jun 2011 16:20:44 -0700 Message-id: <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.1237.1) X-Brightmail-Tracker: AAAAAA== Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 23:21:53 -0000 On Jun 8, 2011, at 2:32 PM, Dmitry Anipko wrote: > > [...] And it unclear to me why IETF would want to take away a _transition_ technique from people for whom it is working... Let's be very clear. This proposed RFC would not "take away" the 6to4 transition mechanism. The working group considered and rejected the idea of publishing a phase-out plan. This draft sets no new requirements for most current vendors of 6to4-capable equipment. It is a purely procedural bill, not a technical one. As such, it will damage no one. This draft does redundantly make some recommendations that are also made in I-D.ietf-v6ops-6to4-advisory, which is the companion document with technical content intended for audiences other than the IETF itself. These recommendations mainly say that 6to4 SHOULD NOT be enabled by DEFAULT. Beyond that, the principle point of this draft is to flip a categorization flag that nobody outside IETF cares about. The practical effect of that will be to free the authors of future working group drafts from a procedural requirement to consider whether 6to4 poses any special problems for the subjects of future standards efforts. I'm okay with that, actually, but I have a hard time imagining how it helps them avoid being pragmatic about what's actually deployed in the real world. Reality must take precedence over public relations, as Professor Feynman said. After much consideration on this draft, I have concluded that every moment IETF spends arguing over it is one that would be put to better use discussing almost anything else... even which cute word we should use for the colon-separated fields in the IPv6 address presentation format. Publish it. Publish it now. Let its authors be free to pursue more useful ends than defending it. -- james woodyatt member of technical staff, core os networking From moore@network-heretics.com Wed Jun 8 17:31:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB5B21F849B; Wed, 8 Jun 2011 17:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.891 X-Spam-Level: X-Spam-Status: No, score=-2.891 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91UywH305h8c; Wed, 8 Jun 2011 17:31:54 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7B021F849A; Wed, 8 Jun 2011 17:31:54 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id 08EB92076B; Wed, 8 Jun 2011 20:31:54 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 08 Jun 2011 20:31:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=uJD0w953a2cjEEHkMJaAXbnLZyo=; b=krw3s37onM1VxMcybmoiAPlFBuaLej4DC6Emb5ICC4OPQXUNQ7zfV8iejzCmcG5FDSjAOrjdnW/nIuhes2Eg/BvcytkQIp4f2zLpZXiR2l8yM5Ie5BClWFkRfC/TVA4CuMlszac14WUuuVNZJcM/0BnWJMNRYj/9iJK7rGbWlNY= X-Sasl-enc: scUcwohD1g/qVidYnmurMmIoCX8z5xcsEbQ/eqjg6g3x 1307579513 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id AB08B4013BE; Wed, 8 Jun 2011 20:31:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Wed, 8 Jun 2011 20:31:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1B27E3A5-3882-4801-ADDF-0E90A848F259@network-heretics.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB0690A2B5@PRVPEXVS04.corp.twcable.com> <24F8A8B2-3AA7-47F4-9AC3-52CCF5C8DF34@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" , ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 00:31:55 -0000 On Jun 8, 2011, at 7:05 PM, Tim Chown wrote: > On 8 Jun 2011, at 21:19, Keith Moore wrote: >>=20 >> Nor, bluntly, is it about a few big content providers or whomever = else you want to label as important. The internet is a hugely diverse = place, and you don't get to dismiss the concerns of people whom you want = to label as red herrings. Again, 40-something percent of the IPv6 = traffic that is observed on the net today uses 6to4. That's about as = much as Teredo, it's a hell of a lot more than native v6. As long as = 6to4 is one of the major ways that people get IPv6 connectivity (and it = clearly is), it's premature to declare 6to4 historic. >=20 > You see 40% of your IPv6 traffic as 6to4, we see rather less than 1%. = Our observation point is as a university on an academic/research network = that is native dual-stack. We probably have most of our IPv6 traffic = come from other universities around the world, who are also most likely = natively connected. Hence little if any need for transition methods. = This may be different to your scenario, of course, but it is hopefully a = future that will be more widespread in time. I'd love it if we all saw a lot more native IPv6 traffic soon.=20 Just to clarify, the 40% is not from my measurement. It's an = approximation to figures I've seen quoted elsewhere. Like you, I'm = sure this figure will vary from place to place. I haven't tried to do = any measurement myself, because the amount of traffic is not a good = indicator of overall usefulness. On the other hand, if any transit = provider anywhere in the world is seeing 40% of v6 traffic as 6to4, that = is a pretty good indication that somebody (besides myself) is using it. =20= For that matter, the very fact that operators are observing problems = with relay routers is another indication that people are using 6to4. = Why would they be using it if they didn't want to? I realize that some = platforms enable 6to4 by default, but not all of them do. And I've = already said I support having hosts and routers ship with 6to4 disabled = by default. > We did use 6to4 in its router-to-router, site-to-site flavour many = years ago while a project called 6NET ran, but have had no use case for = it since. Perhaps it would be useful to see your use cases more clearly = documented with examples. I've already given examples. People keep looking for more specific = examples in an argument where any specific example can be dismissed as = irrelevant. It's not any one specific example that matters, it's the = fact that people are using 6to4 and there's not an obviously better = replacement that's available to them. > The problem is that 6to4 is unfortunately also harmful to real users, = at least the ones that don't want to know about IPv6. It will continue = to be until we can be confident no vendor anywhere has 6to4 on by = default, won't it? NATs are harmful to real users too, and they do a lot more harm than = 6to4 does. When will we deprecate them? When will we declare them = Historic? It's misleading to talk about only the harm being done by 6to4 without = acknowledging the benefits of 6to4 or the lack of a suitable = alternative. And to say that 6to4 does harm is misleading. Is it 6to4 = that's doing the harm, or people who advertise routes to relay routers = that don't function properly? Why are people blaming the 6to4 protocol = for configuration errors made by network operators? > The question is whether Historic stops knowledgeable people like you = using 6to4 safely in your own context/community, without affecting = 'normal' users. Does it mean 6to4 off be default, or 6to4 removed from = product? Historic doesn't stop someone who can write his own code. But if it = results in implementations removing support for 6to4, declaring 6to4 as = Historic will stop people who use those implementations. >> It's not one versus the other. 6to4 is helping to promote = ubiquitous IPv6. >=20 > The other view is that 6to4 is delaying ubiquitous IPv6 deployment, by = adding brokenness. Geoff's stats illustrate that very well, though those = are not based on vanilla 6to4. I disagree with that assessment, because it's only considering the case = of using 6to4 when IPv4 would work just fine. That's not an = appropriate metric. Nobody who has native IPv6 connectivity needs to = use 6to4 to reach native IPv6 destination addresses. =20 But a deeper problem is the notion that a single set of address = selection rules will work well for all, or even most, applications. Keith From gert@space.net Wed Jun 8 22:54:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1015E11E8074 for ; Wed, 8 Jun 2011 22:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bFz+kGON7qV for ; Wed, 8 Jun 2011 22:54:53 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 96B9D22800A for ; Wed, 8 Jun 2011 22:54:50 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id F293FF8164 for ; Thu, 9 Jun 2011 07:54:47 +0200 (CEST) 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 D7246F8179 for ; Thu, 9 Jun 2011 07:54:47 +0200 (CEST) Received: (qmail 52803 invoked by uid 1007); 9 Jun 2011 07:54:47 +0200 Date: Thu, 9 Jun 2011 07:54:47 +0200 From: Gert Doering To: james woodyatt Message-ID: <20110609055447.GJ45955@Space.Net> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org WG" , ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 05:54:54 -0000 Hi, On Wed, Jun 08, 2011 at 04:20:44PM -0700, james woodyatt wrote: > Publish it. Publish it now. Let its authors be free to pursue more useful ends than defending it. Well said. +1 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 moore@network-heretics.com Thu Jun 9 07:38:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A33611E80ED; Thu, 9 Jun 2011 07:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m61qD43RGNHB; Thu, 9 Jun 2011 07:38:00 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 483C511E80E1; Thu, 9 Jun 2011 07:38:00 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 512D720399; Thu, 9 Jun 2011 10:37:59 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 09 Jun 2011 10:37:59 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=5y4vauCwBv0RNJbaZXWyHhWBB20=; b=jKQ1F97IfQbgGhNgp9IV0AV0lIYR8NU/frLHM2wYjnECepap0iFwGkYXS8DGB8YpOpKxpL05KJcabS1qRy7Es7W56j8c0DpkGql5CcR6F7MfB+0K5KegCpyrSVKOM2rzPS3RxDaO+Zg4Tdgp3O5BOOQo2JBci0g8zKlbS4htxZ4= X-Sasl-enc: knppnJKbfOaOOqGaDIs+JaQceKlMC94XICs/Qiy45T6C 1307630278 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 0F44F445183; Thu, 9 Jun 2011 10:37:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> Date: Thu, 9 Jun 2011 10:37:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" , ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:38:01 -0000 On Jun 8, 2011, at 7:20 PM, james woodyatt wrote: > On Jun 8, 2011, at 2:32 PM, Dmitry Anipko wrote: >>=20 >> [...] And it unclear to me why IETF would want to take away a = _transition_ technique from people for whom it is working... >=20 > Let's be very clear. This proposed RFC would not "take away" the 6to4 = transition mechanism. The working group considered and rejected the = idea of publishing a phase-out plan. This draft sets no new = requirements for most current vendors of 6to4-capable equipment. It is = a purely procedural bill, not a technical one. As such, it will damage = no one. I have also seen those claims in v6ops email (haven't caught up with all = of it, but have seen a few messages). I don't buy the argument. = Clearly the intent of this draft and protocol action are to discourage = use of 6to4, particularly in new implementations. You can't discourage = use of 6to4 in new implementations without harming people who are = already using it and depending on it. =20 (That would be a bit like declaring IPv4 Historic and discouraging new = implementations from supporting it - when we all know that there will be = people using IPv4 in corner cases for many years even after the public = Internet no longer routes it. Legacy hardware and software that's still = in use, etc.) When the draft is clearly intended to do harm to 6to4, and there are = clearly people using 6to4 in the Real World, it strikes me as = disingenuous for its proponents to claim that the document will do no = harm. > Publish it. Publish it now. Let its authors be free to pursue more = useful ends than defending it. The authors are already free to abandon the effort and pursue more = useful ends. Not only would publishing this do harm to 6to4 and its = users, it would set a bad precedent. We're supposed to be working = toward consensus, not trying to cause harm to things that people use. Keith From gvandeve@cisco.com Thu Jun 9 07:59:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A74A21F850D; Thu, 9 Jun 2011 07:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNho5ILohqDq; Thu, 9 Jun 2011 07:59:11 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id F116821F8509; Thu, 9 Jun 2011 07:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=2568; q=dns/txt; s=iport; t=1307631551; x=1308841151; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=sYqOf4pep999j1eyv8wQtUBJENkYQo8qdgk7H/tLiQM=; b=g9eWVZrVXShVfXsShVghI99RFTCvCDroEr2yAFU8NjXxeV/gq97TgVVA gIQhCUWJRWg7wxGJeMUGMQ+drqXzhiEFI+slqPjhug+irJLBIYXIroyAt PvbaSGfBCXnvTOzYmOWziNVkqAtJ3msr6sM9PGltky7gxQcIf6JMMQwGf 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFXf8E2Q/khL/2dsb2JhbABTpjp3iHGhJZ4bhiMElgCKfg X-IronPort-AV: E=Sophos;i="4.65,342,1304294400"; d="scan'208";a="34491362" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 09 Jun 2011 14:59:10 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p59ExAVi029488; Thu, 9 Jun 2011 14:59:10 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, 9 Jun 2011 16:59:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jun 2011 16:59:09 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E503D14295@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC Thread-Index: Acwmsyf6vb/PehSIRTay9jH3mZgfawAAZNaw References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com><34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com><08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com><34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com><840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com><677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> From: "Gunter Van de Velde (gvandeve)" To: "Keith Moore" , "james woodyatt" X-OriginalArrivalTime: 09 Jun 2011 14:59:09.0923 (UTC) FILETIME=[C98BF330:01CC26B5] Cc: v6ops@ietf.org, ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:59:15 -0000 Its 'rough' consensus... I don't wanna rat-hole here, but imho send the draft onwards for publication asap please. G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Keith Moore Sent: 09 June 2011 16:38 To: james woodyatt Cc: v6ops@ietf.org WG; ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC On Jun 8, 2011, at 7:20 PM, james woodyatt wrote: > On Jun 8, 2011, at 2:32 PM, Dmitry Anipko wrote: >>=20 >> [...] And it unclear to me why IETF would want to take away a _transition_ technique from people for whom it is working... >=20 > Let's be very clear. This proposed RFC would not "take away" the 6to4 transition mechanism. The working group considered and rejected the idea of publishing a phase-out plan. This draft sets no new requirements for most current vendors of 6to4-capable equipment. It is a purely procedural bill, not a technical one. As such, it will damage no one. I have also seen those claims in v6ops email (haven't caught up with all of it, but have seen a few messages). I don't buy the argument. Clearly the intent of this draft and protocol action are to discourage use of 6to4, particularly in new implementations. You can't discourage use of 6to4 in new implementations without harming people who are already using it and depending on it. =20 (That would be a bit like declaring IPv4 Historic and discouraging new implementations from supporting it - when we all know that there will be people using IPv4 in corner cases for many years even after the public Internet no longer routes it. Legacy hardware and software that's still in use, etc.) When the draft is clearly intended to do harm to 6to4, and there are clearly people using 6to4 in the Real World, it strikes me as disingenuous for its proponents to claim that the document will do no harm. > Publish it. Publish it now. Let its authors be free to pursue more useful ends than defending it. The authors are already free to abandon the effort and pursue more useful ends. Not only would publishing this do harm to 6to4 and its users, it would set a bad precedent. We're supposed to be working toward consensus, not trying to cause harm to things that people use. Keith _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From moore@network-heretics.com Thu Jun 9 08:05:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B304021F8591; Thu, 9 Jun 2011 08:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LaGINPS1BfA; Thu, 9 Jun 2011 08:05:40 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id A710821F8584; Thu, 9 Jun 2011 08:05:31 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 55E3C20E1B; Thu, 9 Jun 2011 11:05:31 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 09 Jun 2011 11:05:31 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=/wd/LCb19uuJwWP5aJ3gxnSyxW4=; b=KXr+9tKuhVtY17gXZqVywFQDtlOgD1pWxD2K1ex4aqRpsd1pxhY8xBVb0OOUT+lA6bj/VG0uuTvWy/pHDJ5zXpPHiCWy4PJ8Tpw35lpkaDjDkFxdujj8kPefnt57aNyFBTlszDRXfvt4zNIT2sn2Zw9YPntegP57HpmPlZqZCKk= X-Sasl-enc: lrjHu1Mmn9CeCX1ilqhsIo5RyJhSn6O9gXbOjvXvTOVq 1307631930 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 32DF0446A50; Thu, 9 Jun 2011 11:05:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E503D14295@XMB-AMS-101.cisco.com> Date: Thu, 9 Jun 2011 11:05:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com><34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com><08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com><34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com><840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com><677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> <4269EA985EACD24987D82DAE2FEC62E503D14295@XMB-AMS-101.cisco.com> To: "Gunter Van de Velde (gvandeve)" X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 15:05:42 -0000 On Jun 9, 2011, at 10:59 AM, Gunter Van de Velde (gvandeve) wrote: > Its 'rough' consensus... > I don't wanna rat-hole here, but imho send the draft onwards for > publication asap please. I'm not even sure it's rough consensus within the v6ops group. Again, = haven't read all of the messages, but definitely get the impression that = it falls short of consensus. And just to be clear on procedure: - you need more than rough consensus in v6ops, you need rough = community-wide consensus. =20 - the criteria for standards track actions (which this is, despite the = document being labeled as Informational) requires both rough consensus = and technical soundness. The best way to not rat-hole is just to drop the proposed action. =20 Keith From cabo@tzi.org Wed Jun 8 02:12:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E962511E8166; Wed, 8 Jun 2011 02:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFZE1UgRQNIe; Wed, 8 Jun 2011 02:12:01 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2073B11E814E; Wed, 8 Jun 2011 02:11:59 -0700 (PDT) Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p589BoCA021782; Wed, 8 Jun 2011 11:11:50 +0200 (CEST) Received: from [192.168.217.101] (p5B3E605E.dip.t-dialin.net [91.62.96.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 62A6DE45; Wed, 8 Jun 2011 11:11:50 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4DEF3461.8040502@gont.com.ar> Date: Wed, 8 Jun 2011 11:11:49 +0200 Content-Transfer-Encoding: 7bit Message-Id: <93280B67-ACFC-4C5A-BDDC-98686D8FB670@tzi.org> References: <4DE6DD93.507@gont.com.ar> <4DE7D813.3050700@gont.com.ar> <201106021939.p52Jd8rI002414@cichlid.raleigh.ibm.com> <4DEF3461.8040502@gont.com.ar> To: Pekka Savola X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 09 Jun 2011 08:08:04 -0700 Cc: Thomas Narten , IPv6 Operations , IPv6 WG Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 09:12:02 -0000 >> restricting radvd send buffer size to 1452B (that obviously doesn't prevent fragmentation in all cases...) Gruesse, Carsten From gert@space.net Thu Jun 9 08:16:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3932411E80FA for ; Thu, 9 Jun 2011 08:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KY8csOghKmkE for ; Thu, 9 Jun 2011 08:16:43 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id CEB1211E80F6 for ; Thu, 9 Jun 2011 08:16:42 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 46B88F8317 for ; Thu, 9 Jun 2011 17:16:40 +0200 (CEST) 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 21E86F81D7 for ; Thu, 9 Jun 2011 17:16:40 +0200 (CEST) Received: (qmail 36484 invoked by uid 1007); 9 Jun 2011 17:16:40 +0200 Date: Thu, 9 Jun 2011 17:16:40 +0200 From: Gert Doering To: Keith Moore Message-ID: <20110609151640.GQ45955@Space.Net> References: <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> <4269EA985EACD24987D82DAE2FEC62E503D14295@XMB-AMS-101.cisco.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, ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 15:16:44 -0000 Hi, On Thu, Jun 09, 2011 at 11:05:29AM -0400, Keith Moore wrote: > The best way to not rat-hole is just to drop the proposed action. One voice doesn't make it "consensus to drop". 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 pch-b2B3A6689@u-1.phicoh.com Thu Jun 9 08:18:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0480211E8102; Thu, 9 Jun 2011 08:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8-CQ+m6Sn66; Thu, 9 Jun 2011 08:18:44 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id AFBE411E80F8; Thu, 9 Jun 2011 08:18:42 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QUh0G-0001hEC; Thu, 9 Jun 2011 17:18:36 +0200 Message-Id: To: Keith Moore From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> In-reply-to: Your message of "Thu, 9 Jun 2011 10:37:56 -0400 ." Date: Thu, 09 Jun 2011 17:18:25 +0200 Cc: "v6ops@ietf.org WG" , ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 15:18:45 -0000 In your letter dated Thu, 9 Jun 2011 10:37:56 -0400 you wrote: >I have also seen those claims in v6ops email (haven't caught up with all of it >, but have seen a few messages). I don't buy the argument. Clearly the inten >t of this draft and protocol action are to discourage use of 6to4, particularl >y in new implementations. You can't discourage use of 6to4 in new implementat >ions without harming people who are already using it and depending on it. > >(That would be a bit like declaring IPv4 Historic and discouraging new impleme >ntations from supporting it - when we all know that there will be people using > IPv4 in corner cases for many years even after the public Internet no longer >routes it. Legacy hardware and software that's still in use, etc.) > >When the draft is clearly intended to do harm to 6to4, and there are clearly p >eople using 6to4 in the Real World, it strikes me as disingenuous for its prop >onents to claim that the document will do no harm. I think this is likely to happen anyway. In all discussions it has been come clear that 6to4 has nothing to offer for ordinary users, and that the situation is going to get worse over time (more NAT, more broken 6to4 installation). So for any CPE manufacturer is makes perfect sense to start planning on dropping support for 6to4 in future CPEs, or not add it at all, if they have yet to release firmware with IPv6 support. This is independent of whether the protocol is declared historic. On the other hand, there is no reason why open source distribution would have to drop 6to4 support. As long as there are people to maintain it, it can stay. Also on other operation systems, as long as there is some sort of tunnel interface, you can implement 6to4. It is just a few lines of code, everybody can do it. So I don't see the big fuzz. If you want to use it, just create a web page that lists software implementation of 6to4 for every possible platform. And let the authors of the software know have much their software is appreciated. From joelja@bogus.com Thu Jun 9 08:20:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36A111E8106; Thu, 9 Jun 2011 08:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.398 X-Spam-Level: X-Spam-Status: No, score=-101.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRB3Ef-mMZIu; Thu, 9 Jun 2011 08:20:05 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5138911E80F8; Thu, 9 Jun 2011 08:20:04 -0700 (PDT) Received: from 000154tjennings.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p59FK0Kn086266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 9 Jun 2011 15:20:01 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8-760597162 From: Joel Jaeggli In-Reply-To: Date: Thu, 9 Jun 2011 08:19:55 -0700 Message-Id: <86D615E0-AC0B-49C1-8CFB-1E80D261CA62@bogus.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com><34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com><08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com><34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com><840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com><677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> <4269EA985EACD24987D82DAE2FEC62E503D14295@XMB-AMS-101.cisco.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 09 Jun 2011 15:20:02 +0000 (UTC) Cc: v6ops@ietf.org, ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 15:20:06 -0000 --Apple-Mail-8-760597162 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 9, 2011, at 8:05 AM, Keith Moore wrote: > On Jun 9, 2011, at 10:59 AM, Gunter Van de Velde (gvandeve) wrote: >=20 >> Its 'rough' consensus... >> I don't wanna rat-hole here, but imho send the draft onwards for >> publication asap please. >=20 > I'm not even sure it's rough consensus within the v6ops group. Again, = haven't read all of the messages, but definitely get the impression that = it falls short of consensus. If you disagree the wg chairs conclusions as far as the wg process = outcome and the document shepherds report which can you can find here: = https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/history= / Then you should consider talking to the responsible ad or an appeal to = the IESG. As far as I am concerned the accusation that the process has = gone off the rails is a seperate issue from the merits or lack thereof = of the proposal. > And just to be clear on procedure: >=20 > - you need more than rough consensus in v6ops, you need rough = community-wide consensus. =20 This is an ietf last call...=20 > - the criteria for standards track actions (which this is, despite the = document being labeled as Informational) requires both rough consensus = and technical soundness. Informational status was at the behest of the iesg, we have been advised = that an informational document may confer historical status on a = standards track document. > The best way to not rat-hole is just to drop the proposed action. =20 >=20 > Keith >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail-8-760597162 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Jun 9, 2011, at 10:59 AM, Gunter Van de Velde (gvandeve) = wrote:

Its 'rough' = consensus...
I don't wanna = rat-hole here, but imho send the draft onwards = for
publication asap = please.

I'm not even sure it's rough consensus = within the v6ops group.  Again, haven't read all of the messages, = but definitely get the impression that it falls short of = consensus.

If you disagree the = wg chairs conclusions as far as the wg process outcome and the document = shepherds report which can you can find = here:


Then you should consider = talking to the responsible ad or an appeal to the IESG. As far as I am = concerned the accusation that the process has gone off the rails is a = seperate issue from the merits or lack thereof of the = proposal.

And just to be clear = on procedure:

- you need more than rough consensus in v6ops, you = need rough community-wide consensus. =  

This is an ietf last = call... 

- the criteria for = standards track actions (which this is, despite the document being = labeled as Informational) requires both rough consensus and technical = soundness.

Informational = status was at the behest of the iesg, we have been advised that an = informational document may confer historical status on a standards track = document.

The best = way to not rat-hole is just to drop the proposed action. =  

Keith

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


= --Apple-Mail-8-760597162-- From rogerj@gmail.com Thu Jun 9 08:24:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35E011E80FD; Thu, 9 Jun 2011 08:24:15 -0700 (PDT) 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=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eM+mvycYua8; Thu, 9 Jun 2011 08:24:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D528B11E810B; Thu, 9 Jun 2011 08:24:13 -0700 (PDT) Received: by wyb29 with SMTP id 29so1365998wyb.31 for ; Thu, 09 Jun 2011 08:24:13 -0700 (PDT) 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=qkqcjZcBw+UVE0NNR/d+aBA1ri+m9pgXSe5VAKJutQM=; b=fkL0W/JB7BNAon4VuB0FClSsuQkfqIXJZtlfiWPQIwHcKG2zoJSnlxH/i1gcHPvAYH /ggE9Ixj4f7Ll7cj5QehWRYAXgU4fCbhDbIheWEgvkpZuaQUZ7M6N6HIdWqesquwxVJj Xeh+DuDpJppvXj3YUxVcSMfxP+DrM/QyHq0o8= 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=AfJ0AMqdqnYFtua31yj9Yu3E7KzuK97vJ0UwvHxGpslGxTA+bDezDGmur3kZ5utj4T SL3wGEABnWcPPPto9tYxIIqSBdTparyva9QWUcyoSkaWQwInUTXkxDFPq5RWPJdbfqnb mP5R+qmaeYwGGljBPVfIkGchNzwSdlJv5Wv0c= MIME-Version: 1.0 Received: by 10.227.55.67 with SMTP id t3mr927492wbg.90.1307633052890; Thu, 09 Jun 2011 08:24:12 -0700 (PDT) Received: by 10.227.132.142 with HTTP; Thu, 9 Jun 2011 08:24:12 -0700 (PDT) In-Reply-To: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> <4269EA985EACD24987D82DAE2FEC62E503D14295@XMB-AMS-101.cisco.com> Date: Thu, 9 Jun 2011 17:24:12 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 15:24:15 -0000 On Thu, Jun 9, 2011 at 5:05 PM, Keith Moore wr= ote: > On Jun 9, 2011, at 10:59 AM, Gunter Van de Velde (gvandeve) wrote: >> Its 'rough' consensus... >> I don't wanna rat-hole here, but imho send the draft onwards for >> publication asap please. > > I'm not even sure it's rough consensus within the v6ops group. =A0Again, = haven't read all of the messages, but definitely get the impression that it= falls short of consensus. There were quite heavy discussion and in the end, there were a few that was totally against it, the rest supported the document. No point in repeating that entire discussion here really, go back and look at the archive. > And just to be clear on procedure: > > - you need more than rough consensus in v6ops, you need rough community-w= ide consensus. > - the criteria for standards track actions (which this is, despite the do= cument being labeled as Informational) requires both rough consensus and te= chnical soundness. > > The best way to not rat-hole is just to drop the proposed action. Let's take a few step back and think about what we are trying to achieve here, what is our goal. IPv6 for everyone for any price? A IPv6 only world? A world where both IPv4 and IPv6 work or? I will claim our goal is native IPv6 along IPv4, and in the long run, IPv6 = only. We don't need more tunneling of IPv6 over IPv4, that was okay 10years ago, maybe even 5 or 3 years ago. Now it is time to actual do the right thing and say "let's do it properly, let's do IPv6 native". ...and stop discussing yesterdays technology. --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From moore@network-heretics.com Thu Jun 9 08:42:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5486811E80E1; Thu, 9 Jun 2011 08:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.811 X-Spam-Level: X-Spam-Status: No, score=-3.811 tagged_above=-999 required=5 tests=[AWL=1.188, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwX3QPq8Xr39; Thu, 9 Jun 2011 08:42:41 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 00DDF11E808B; Thu, 9 Jun 2011 08:42:40 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 76D5720DCE; Thu, 9 Jun 2011 11:42:40 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 09 Jun 2011 11:42:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=T4irFEBm68YXf1TyUtLbQob/qQg=; b=bI78FXhzxXHMnOsmuOpfC4bRkLJXnfPwlbzQLKNBkRLnAUP5kBemSmN1i6oEAJOQW1Ucv5C49YSsy73DC4LYKeutgsUML2UUxtO8d/AICbLiODQe0XFhIaSWw9oLFxmVZ+rWh5J6SVapXlO0IHh4+P3g8591pM8Mpx42PUbq6VY= X-Sasl-enc: haGFmkhE5FelPfd4ILOPV9kuQBcXnNF1RzAlmPglXCTG 1307634159 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 03A63443C55; Thu, 9 Jun 2011 11:42:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Thu, 9 Jun 2011 11:42:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" , ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 15:42:42 -0000 On Jun 9, 2011, at 11:18 AM, Philip Homburg wrote: > In your letter dated Thu, 9 Jun 2011 10:37:56 -0400 you wrote: >> I have also seen those claims in v6ops email (haven't caught up with = all of it >> , but have seen a few messages). I don't buy the argument. Clearly = the inten >> t of this draft and protocol action are to discourage use of 6to4, = particularl >> y in new implementations. You can't discourage use of 6to4 in new = implementat >> ions without harming people who are already using it and depending on = it. =20 >>=20 >> (That would be a bit like declaring IPv4 Historic and discouraging = new impleme >> ntations from supporting it - when we all know that there will be = people using >> IPv4 in corner cases for many years even after the public Internet no = longer=20 >> routes it. Legacy hardware and software that's still in use, etc.) >>=20 >> When the draft is clearly intended to do harm to 6to4, and there are = clearly p >> eople using 6to4 in the Real World, it strikes me as disingenuous for = its prop >> onents to claim that the document will do no harm. >=20 > I think this is likely to happen anyway. In all discussions it has = been come > clear that 6to4 has nothing to offer for ordinary users, and that the = situation > is going to get worse over time (more NAT, more broken 6to4 = installation). I don't buy the notion that "ordinary users" only use some small number = of killer apps. "ordinary users" are quite diverse. I certainly agree that increased deployment of LSN will do harm to 6to4 = and its users. This wouldn't bother me if ISPs were going to roll out a = native v6 solution concurrently with LSNs, but my impression is that v6 = support is going to lag LSN imposition. > So for any CPE manufacturer is makes perfect sense to start planning = on > dropping support for 6to4 in future CPEs, or not add it at all, if = they have > yet to release firmware with IPv6 support. I agree that v4 CPE manufacturers, at least those for consumer = applications where the networks are likely to be saddled with LSN, = certainly should not automatically enable 6to4 in their products. =20 There's some justification for their not implementing it at all. = However it's my experience that "consumer" CPEs are often used to = provide connectivity for small business customers also. In general, LSN = is not suitable for those customers, and they could benefit from 6to4 = support in the CPE. But I'm more concerned about the potential for this action to result in = 6to4 support being prematurely removed from hosts, than I am about its = effects on CPEs. =20 > This is independent of whether the protocol is declared historic. >=20 > On the other hand, there is no reason why open source distribution = would=20 > have to drop 6to4 support. As long as there are people to maintain it, = it > can stay. Also on other operation systems, as long as there is some = sort of > tunnel interface, you can implement 6to4. It is just a few lines of = code,=20 > everybody can do it. "A few lines of code" imposes a significant barrier. I've done a fair = amount of kernel hacking in the past, written device drivers, and = brought up Linux and FreeBSD and NetBSD (in that order) on laptops back = in the days when laptop hardware was really flaky and poorly documented = and there was no support in the kernels for their network interfaces. = I'm not scared of writing kernel-level C code. But I don't do it all = the time, and realistically it would take me several days to fetch the = source code, update myself on the build process, and figure out exactly = how to re-insert 6to4 into the kernel. And that's for Linux or NetBSD = - I have less familiarity with MacOS and other kernels. And I'd have no = idea about how to retro-fit 6to4 into Windows if support for it were = removed. I generally don't write code for Windows, but I am = occasionally forced to use it. And somehow I suspect that my skills in this area are considerably more = than the typical 6to4 user. > So I don't see the big fuzz. If you want to use it, just create a web = page > that lists software implementation of 6to4 for every possible = platform. And > let the authors of the software know have much their software is = appreciated. Similarly, I don't see why there's such a desire to deprecate 6to4 and = declare it Historic. It's the first time I can recall a proposal to = move something to Historic that was widely deployed, widely used, and = for which there was no suitable and widely available replacement. Nor do I understand why, in an organization that is supposedly about = building consensus, there's such a demand for a divisive and obviously = harmful action. Generally the way you build consensus is by focusing on = things for which there is wide agreement, and crafting compromises on = the other things. But the proponents of this draft have taken a 'no = compromise' position. Keith From moore@network-heretics.com Thu Jun 9 08:51:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AF711E810F; Thu, 9 Jun 2011 08:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuaLDG0aAxZ3; Thu, 9 Jun 2011 08:50:59 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id A768A11E80F4; Thu, 9 Jun 2011 08:50:59 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 3806320E3F; Thu, 9 Jun 2011 11:50:59 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 09 Jun 2011 11:50:59 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=TBY9dNQwwHR/6lEks8sSkhxYq90=; b=R20ByUM8EA6IKs4lRJ7S/TBcTGh5IuVKtNPb6qHlZ3CT1BTc1JBO0ame0TRufVWmbclA1KF6UYn3lk3x/GPpWg5Ew4B9nbnR5uKc+27T22Y0Ak+0oXktfIcmoD/HRqqAyHmEGRR99H2rGQGQ7J87+H/3P89wfiAQ2YeXw2Xttrw= X-Sasl-enc: Fmxbwr/EEPAoZ98uz7grcOmUXmu94mz2Y1TiPe6jHulB 1307634658 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 9FC7A440290; Thu, 9 Jun 2011 11:50:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-23-762458593 From: Keith Moore In-Reply-To: <86D615E0-AC0B-49C1-8CFB-1E80D261CA62@bogus.com> Date: Thu, 9 Jun 2011 11:50:56 -0400 Message-Id: <4816E77C-C42B-4145-B115-1E6A53AF6002@network-heretics.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com><34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com><08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com><34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com><840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com><677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> <4269EA985EACD24987D82DAE2FEC62E503D14295@XMB-AMS-101.cisco.com> <86D615E0-AC0B-49C1-8CFB-1E80D261CA62@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 15:51:02 -0000 --Apple-Mail-23-762458593 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 9, 2011, at 11:19 AM, Joel Jaeggli wrote: > If you disagree the wg chairs conclusions as far as the wg process = outcome and the document shepherds report which can you can find here: >=20 > = https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/history= / > Then you should consider talking to the responsible ad or an appeal to = the IESG. As far as I am concerned the accusation that the process has = gone off the rails is a seperate issue from the merits or lack thereof = of the proposal. I agree that it's a separate issue, and should be treated separately. = Again, I haven't read all of the discussion, probably won't have time to = do that for several more days, and will withhold a decision about any = process appeal until I've done so. =20 (And frankly, if IESG wants to sabotage 6to4 also, I doubt that a = process appeal would do any good. I'll argue vigorously for something = that I think is useful and/or important, but I have no interest in = making hard-working people's lives harder for no good reason.) >> And just to be clear on procedure: >>=20 >> - you need more than rough consensus in v6ops, you need rough = community-wide consensus. =20 >=20 > This is an ietf last call...=20 indeed. I just wanted to counter the possibly-implied assertion that = v6ops rough consensus was sufficient. >> - the criteria for standards track actions (which this is, despite = the document being labeled as Informational) requires both rough = consensus and technical soundness. >=20 > Informational status was at the behest of the iesg, we have been = advised that an informational document may confer historical status on a = standards track document. I don't have a problem with the idea that an Informational document can = describe the consequences of moving something to Historic. I have a = serious problem with the idea that a standards-track document can be = moved off of the standards track by less than an IETF Consensus process, = or by ignoring the criteria for standards-track actions. I haven't seen = any evidence that IESG is trying to do that - they are doing a Last Call = after all. But I don't think we want to set a precedent that removing = something from the standards track is easier or requires less scrutiny = of the technical criteria than putting something on the standards track. Keith --Apple-Mail-23-762458593 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
If you disagree the = wg chairs conclusions as far as the wg process outcome and the document = shepherds report which can you can find = here:

Then you = should consider talking to the responsible ad or an appeal to the IESG. = As far as I am concerned the accusation that the process has gone off = the rails is a seperate issue from the merits or lack thereof of the = proposal.

I agree that it's = a separate issue, and should be treated separately.  Again, I = haven't read all of the discussion, probably won't have time to do that = for several more days, and will withhold a decision about any process = appeal until I've done so.  

(And frankly, = if IESG wants to sabotage 6to4 also, I doubt that a process appeal would = do any good.  I'll argue vigorously for something that I think is = useful and/or important, but I have no interest in making hard-working = people's lives harder for no good reason.)

And just to be clear on procedure:

- you need = more than rough consensus in v6ops, you need rough community-wide = consensus.  

This is an = ietf last = call... 

indeed. =  I just wanted to counter the possibly-implied assertion that v6ops = rough consensus was sufficient.

- the criteria for standards track actions (which = this is, despite the document being labeled as Informational) requires = both rough consensus and technical = soundness.

Informational = status was at the behest of the iesg, we have been advised that an = informational document may confer historical status on a standards track = document.

I don't have a = problem with the idea that an Informational document can describe the = consequences of moving something to Historic.  I have a serious = problem with the idea that a standards-track document can be moved off = of the standards track by less than an IETF Consensus process, or by = ignoring the criteria for standards-track actions.  I haven't seen = any evidence that IESG is trying to do that - they are doing a Last Call = after all.  But I don't think we want to set a precedent that = removing something from the standards track is easier or requires less = scrutiny of the technical criteria than putting something on the = standards = track.

Keith

= --Apple-Mail-23-762458593-- From moore@network-heretics.com Thu Jun 9 08:54:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C0B11E812B; Thu, 9 Jun 2011 08:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.738 X-Spam-Level: X-Spam-Status: No, score=-2.738 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+DeipEGlx68; Thu, 9 Jun 2011 08:54:22 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6016211E8132; Thu, 9 Jun 2011 08:54:19 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 016DB20E49; Thu, 9 Jun 2011 11:54:19 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 09 Jun 2011 11:54:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=Yw2LxzPjjBK7aY/qZO+ejdrPsm8=; b=V/GrSoEXas67NGGbHn1gnOmjpi9zOFtppkj+MOpuvRS10sHdnAPvbgqxoByO1yIKaJRsHAtFNojob46Ehb3XFsLuTbbk+PsIwmhtpR9986A4jPyzzCe9fT/RJGKGyRF7NPzU5tIcnzW27vDxbr7NsKbxeFQSwFE8nwtSQ0XfuGQ= X-Sasl-enc: u3RMdmb0p9rUltFsuTl9ahGeccEzuzBE8GvFDyH6ngyp 1307634858 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id D3795441812; Thu, 9 Jun 2011 11:54:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: Date: Thu, 9 Jun 2011 11:54:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> <4269EA985EACD24987D82DAE2FEC62E503D14295@XMB-AMS-101.cisco.com> To: =?iso-8859-1?Q?Roger_J=F8rgensen?= X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 15:54:24 -0000 On Jun 9, 2011, at 11:24 AM, Roger J=F8rgensen wrote: > I will claim our goal is native IPv6 along IPv4, and in the long run, = IPv6 only. > We don't need more tunneling of IPv6 over IPv4, that was okay 10years > ago, maybe even 5 or 3 years ago. > Now it is time to actual do the right thing and say "let's do it > properly, let's do IPv6 native". The time to actually do the right thing was also 10-15 years ago. But = native v6, for the most part, is still not here yet. At least the ISPs = are saying Real Soon Now, which is something. But who knows what "Real = Soon" means? Until native IPv6 is actually here, where "here" means = "everywhere", there is still a need to do tunneling of v6 over v4. > ...and stop discussing yesterdays technology. We're always discussing yesterday's technology. IPv6 was approved in = 1995, if I recall. =20 Keith From huitema@microsoft.com Thu Jun 9 09:01:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F0822800B; Thu, 9 Jun 2011 09:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4bDriJJV3CF; Thu, 9 Jun 2011 09:01:41 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id DE466228004; Thu, 9 Jun 2011 09:01:40 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 9 Jun 2011 09:01:40 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 9 Jun 2011 09:01:40 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.58]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Thu, 9 Jun 2011 09:01:39 -0700 From: Christian Huitema To: Keith Moore , Philip Homburg Thread-Topic: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC Thread-Index: AQHMJrv/oyGIAbwZ4kyG6HE2x5uidpS1K0zA Date: Thu, 9 Jun 2011 16:01:39 +0000 Message-ID: <22F6318E46E26B498ABC828879B08D4F167D15@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 09 Jun 2011 09:10:23 -0700 Cc: "v6ops@ietf.org WG" , "ietf@ietf.org" Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 16:01:41 -0000 Arguably, transitions technologies like 6to4 and Teredo have already achiev= ed their purpose. My goal at the time, more than 10 years ago, was to break= the "chicken and egg" deadlock between application developers and network = administrators. That's why I spent such energy on making 6to4 easy to deplo= y, or defining Teredo. Transitions technologies convinced developers that a= pplications could be developed for IPv6 without waiting for every network t= o be ready, and applications were indeed developed by Microsoft and others.= Network administrators in the meantime started deploying IPv6, and the pre= sence of applications arguably helped somewhat -- although I am sure networ= k administrators add many other motivations. We are now observing a strong pushback, because massive use of tunneling te= chnologies makes networks harder to manage. Wide scale deployment of self-c= onfiguring technologies makes levels of services less predictable, and erro= rs are hard to correct. Self-configuring technologies rely largely on the g= ood will of others, which is easier to find during a pioneering phase. Argu= ably, we are beyond the pioneering phase for IPv6. I understand Keith's point of view, but it is probably time to start progre= ssively rolling back the transition technologies. 6to4 is the weakest of th= ese technologies. It does not traverse NAT, it does not include configurati= on verification tests, and it uses asymmetric paths. It makes sense to star= t the rollback with 6to4. -- Christian Huitema From joelja@bogus.com Thu Jun 9 09:17:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E8611E8133; Thu, 9 Jun 2011 09:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMJMd71vTJbV; Thu, 9 Jun 2011 09:17:24 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 147BE11E8144; Thu, 9 Jun 2011 09:17:22 -0700 (PDT) Received: from 000154tjennings.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p59GHIT3087712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 9 Jun 2011 16:17:20 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <4816E77C-C42B-4145-B115-1E6A53AF6002@network-heretics.com> Date: Thu, 9 Jun 2011 09:17:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com><34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com><08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com><34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com><840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com><677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> <4269EA985EACD24987D82DAE2FEC62E503D14295@XMB-AMS-101.cisco.com> <86D615E0-AC0B-49C1-8CFB-1E80D261CA62@bogus.com> <4816E77C-C42B-4145-B115-1E6A53AF6002@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 09 Jun 2011 16:17:20 +0000 (UTC) Cc: v6ops@ietf.org, ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 16:17:24 -0000 On Jun 9, 2011, at 8:50 AM, Keith Moore wrote: >=20 >>> - the criteria for standards track actions (which this is, despite = the document being labeled as Informational) requires both rough = consensus and technical soundness. >>=20 >> Informational status was at the behest of the iesg, we have been = advised that an informational document may confer historical status on a = standards track document. >=20 > I don't have a problem with the idea that an Informational document = can describe the consequences of moving something to Historic. I have a = serious problem with the idea that a standards-track document can be = moved off of the standards track by less than an IETF Consensus process, = or by ignoring the criteria for standards-track actions. I haven't seen = any evidence that IESG is trying to do that - they are doing a Last Call = after all. But I don't think we want to set a precedent that removing = something from the standards track is easier or requires less scrutiny = of the technical criteria than putting something on the standards track. The record will show that that the intended status of the document until = it reached the iegs was standards track. it has been understood from the = outset that advancement of the document was to obsolete 3056 and 3068. = revision 4 at the request of the iesg changed th e intented status to = informational. > Keith >=20 From jnc@mercury.lcs.mit.edu Thu Jun 9 09:25:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557B411E8156; Thu, 9 Jun 2011 09:25:22 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7WoBJYcy6QX; Thu, 9 Jun 2011 09:25:21 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 36BC511E813E; Thu, 9 Jun 2011 09:25:20 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 06A3D18C0F7; Thu, 9 Jun 2011 12:25:17 -0400 (EDT) To: ietf@ietf.org, v6ops@ietf.org Message-Id: <20110609162517.06A3D18C0F7@mercury.lcs.mit.edu> Date: Thu, 9 Jun 2011 12:25:17 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 16:25:22 -0000 > From: Keith Moore > Nor do I understand why, in an organization that is supposedly about > building consensus, there's such a demand for a divisive ... action. Hey, that's been the IPv6 world since day 1. How many leading technical voices in the community objected vociferoursly to the choice of IPv6 back in the day, only to be blown off? (The large number of unhappy people have been, I reckon, a factor in the slow progress of IPv6 since 1995 - although not the larges, IMO.) The more things change... Noel From brian.e.carpenter@gmail.com Thu Jun 9 09:30:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E671711E8188; Thu, 9 Jun 2011 09:30:33 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dp2Pk2UkM1d; Thu, 9 Jun 2011 09:30:33 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 24B8A11E81AF; Thu, 9 Jun 2011 09:29:51 -0700 (PDT) Received: by fxm15 with SMTP id 15so1274071fxm.31 for ; Thu, 09 Jun 2011 09:29:51 -0700 (PDT) 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=e8kCFHcJHyh/7tbVFl51sY1iGx4fc8CwZFceBXMpu+E=; b=Lqj3vAZPz3H8iCzsTsqFWz9/63IvaLnKyHdSzxxcEiRcEYDX9c3QhVY+LlMGKqihfs 2UQQzB90UlhrL4i4nnXiU/giwgTacbAaejRrjCpMlCqL2yU0wCIZCRelwaGqkszLJend A1fI1QW10tgD5vVJ9Zwmxw0gaGONItub6as7E= 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=Ie4P0Dg9u8RUePrs+G0GYRl085VRRK75VbeNTi0r1MA/jVcUO4ronO4GYwEji6bZ6C 57dW92tCChcDbyVCv/mJmcreYbLBDu8KMoluxI9cNMCYh+sw5F930h2p/HjhL0M29B4I 3+UI0cj8+3bvU7WEVV2cbooA6l7Hw3Y9YlaPU= Received: by 10.223.33.80 with SMTP id g16mr1015159fad.125.1307636991168; Thu, 09 Jun 2011 09:29:51 -0700 (PDT) Received: from [10.255.25.89] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id o23sm727639faa.9.2011.06.09.09.29.48 (version=SSLv3 cipher=OTHER); Thu, 09 Jun 2011 09:29:50 -0700 (PDT) Message-ID: <4DF0F4F5.5000308@gmail.com> Date: Fri, 10 Jun 2011 04:29:41 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Homburg References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , Keith Moore , ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 16:30:34 -0000 Philip, On 2011-06-10 03:18, Philip Homburg wrote: ... > I think this is likely to happen anyway. In all discussions it has been come > clear that 6to4 has nothing to offer for ordinary users, In all fairness, that depends on your definition of "ordinary". Where I differ from Keith is that I don't think we harm the current ordinary (or extraordinary) 6to4 users by relabelling the RFCs. As long as all operators do what draft-ietf-v6ops-6to4-advisory suggests, of course. I wouldn't support the -historic draft if the -advisory draft wasn't coming along too. > and that the situation > is going to get worse over time (more NAT, more broken 6to4 installation). More NAT44, yes. But *less* broken 6to4 if operators implement -advisory. Brian From moore@network-heretics.com Thu Jun 9 10:20:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB04A11E81D6; Thu, 9 Jun 2011 10:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vj4ZPxzE77HN; Thu, 9 Jun 2011 10:20:38 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8C86211E81D0; Thu, 9 Jun 2011 10:20:38 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 2E8B020F33; Thu, 9 Jun 2011 13:20:38 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 09 Jun 2011 13:20:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=2CQepiaNOEOUDupWK5KiqeaZ9S8=; b=NdKcwiDGzm7JWsm+gAHRYmf3/fnVH7n1/C3QqnBwKjKk8CTbaKZ8kcnztpK5GpRnKKGWiGHp0rqk8/ML5KxrbfZP1VlhIUZ0u3HQxcyT00eN+uSu1mfyq+t2aXalRBIRKG8jNXEWUrwrrqIohOSFoHU3CKmmZ5o6OfJC23rmEk8= X-Sasl-enc: YlwFa9CcDF5lqmoleUaRcyvSxARQTid3KC+io18EB6jT 1307640037 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 0D807441ADA; Thu, 9 Jun 2011 13:20:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4DF0F4F5.5000308@gmail.com> Date: Thu, 9 Jun 2011 13:20:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> <4DF0F4F5.5000308@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" , ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 17:20:40 -0000 > On 2011-06-10 03:18, Philip Homburg wrote: > ... >> I think this is likely to happen anyway. In all discussions it has = been come >> clear that 6to4 has nothing to offer for ordinary users,=20 >=20 > In all fairness, that depends on your definition of "ordinary". > Where I differ from Keith is that I don't think we harm the current > ordinary (or extraordinary) 6to4 users by relabelling the RFCs. At best, I think it's a waste of time. At worst, I think it will do = harm by reducing the number of host implementations that can use 6to4, = before native IPv6 is widely available. In between those extremes, I think there's a large potential for = confusion from the publication of 6to4-advisory along with declaring = 6to4 historic and discouraging new implementations. On one hand, we're = telling people how to make 6to4 work better. On the other hand, we're = telling people that it's bad and that they shouldn't implement it. = While I've long favored the idea that IETF needs a way to say "this = protocol/practice causes problems and we'd rather you not use it, but if = you do use it please do it this way", in this case we're trying to do it = with two different documents that say somewhat contradictory things to = one another. =20 Really I think that 6to4-advisory should be sufficient. That, and it's = much better written and more balanced. Keith From moore@network-heretics.com Thu Jun 9 10:26:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519A611E81F3; Thu, 9 Jun 2011 10:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwyK+1YgBBDE; Thu, 9 Jun 2011 10:26:41 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 076C511E81EE; Thu, 9 Jun 2011 10:26:40 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id E4D8A207E3; Thu, 9 Jun 2011 13:26:39 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 09 Jun 2011 13:26:39 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=8tBb7GgYW/97uF7pm3fSu8diHic=; b=EJaD3iMu55G8RmK70GKgHJTtGx0U95UlPRRpQ23cwPduRA7OhTrpBHp7TJkHqkLFpZ2J9Soi7yz0txqojolmvOV8rYp+B0nUlLBtzfxyRfmZx2f2pIY8GqnxuH8NzVUufgtpZdcas0ggBJKE2DGsiQmCu/WSW1YXjLM/lTlN4mo= X-Sasl-enc: YbJf8ppZyIM79mQ3A2gt4bFLxP0kTI2B6gUGeIFQp3VE 1307640399 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 9DADC443813; Thu, 9 Jun 2011 13:26:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Thu, 9 Jun 2011 13:26:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com><34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com><08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com><34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com><840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com><677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> <4269EA985EACD24987D82DAE2FEC62E503D14295@XMB-AMS-101.cisco.com> <86D615E0-AC0B-49C1-8CFB-1E80D261CA62@bogus.com> <4816E77C-C42B-4145-B115-1E6A53AF6002@network-heretics.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 17:26:42 -0000 On Jun 9, 2011, at 12:17 PM, Joel Jaeggli wrote: >> I don't have a problem with the idea that an Informational document = can describe the consequences of moving something to Historic. I have a = serious problem with the idea that a standards-track document can be = moved off of the standards track by less than an IETF Consensus process, = or by ignoring the criteria for standards-track actions. I haven't seen = any evidence that IESG is trying to do that - they are doing a Last Call = after all. But I don't think we want to set a precedent that removing = something from the standards track is easier or requires less scrutiny = of the technical criteria than putting something on the standards track. >=20 > The record will show that that the intended status of the document = until it reached the iegs was standards track. it has been understood = from the outset that advancement of the document was to obsolete 3056 = and 3068. revision 4 at the request of the iesg changed th e intented = status to informational. And Informational status *for the document*, if published, is entirely = appropriate. But the *protocol action* is a standards-track protocol = action. It used to not be considered necessary to publish an RFC every time the = IESG approved a protocol action. Somewhere along the way, having a = companion document started to be commonplace. I'm not sure why that got = to be conventional - maybe it was because of increased use of tracking = tools that were written with document processing in mind. And at least = sometimes it's beneficial to the community to publish an RFC that = explains why a particular document's status has changed, and how to = interpret that change in document status. But RFC 2026 didn't = anticipate the need for every protocol action to have an associated = document, and sometimes - as in this case - it causes confusion when = they are associated. Process-wise, I think that the protocol action and the document action = should be separate items. Though of course it makes no sense for IESG = to approve the document if it doesn't approve the protocol action. Keith From moore@network-heretics.com Thu Jun 9 10:39:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DF711E819A; Thu, 9 Jun 2011 10:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4st0AYt9K3FF; Thu, 9 Jun 2011 10:39:10 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 13E6211E8130; Thu, 9 Jun 2011 10:39:10 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 8FB0B20B34; Thu, 9 Jun 2011 13:39:09 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 09 Jun 2011 13:39:09 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=U/G5IQbdOm86Bh0lD64qy6v7nsU=; b=rckj6GEvQk7qaoOuOioDzJUmkCExmET7Oab1MLH0pLAvbMc2YOvwkba8rMaY9w0Gq2dCe1bpqnDFvAUlW5tMCgbycXz4YCDU5i0jS4YuQnqFm/wWq4Vz2HozmZKcffaoHSY+aejHLTGpbp1rs8qF+5570T56TYqdDc5TWI2M4os= X-Sasl-enc: sXmYnMKK1jtM3o81Nu14nyxztt/ybj3bJBvPPIiMezQb 1307641148 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 2B0D3442FBE; Thu, 9 Jun 2011 13:39:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <22F6318E46E26B498ABC828879B08D4F167D15@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 9 Jun 2011 13:39:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0F2C8463-36AA-41D1-8D3F-735A623F484C@network-heretics.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> <22F6318E46E26B498ABC828879B08D4F167D15@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> To: Christian Huitema X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" , "ietf@ietf.org" Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 17:39:11 -0000 On Jun 9, 2011, at 12:01 PM, Christian Huitema wrote: > Arguably, transitions technologies like 6to4 and Teredo have already = achieved their purpose. My goal at the time, more than 10 years ago, was = to break the "chicken and egg" deadlock between application developers = and network administrators. That's why I spent such energy on making = 6to4 easy to deploy, or defining Teredo. Transitions technologies = convinced developers that applications could be developed for IPv6 = without waiting for every network to be ready, and applications were = indeed developed by Microsoft and others. Network administrators in the = meantime started deploying IPv6, and the presence of applications = arguably helped somewhat -- although I am sure network administrators = add many other motivations. >=20 > We are now observing a strong pushback, because massive use of = tunneling technologies makes networks harder to manage. Wide scale = deployment of self-configuring technologies makes levels of services = less predictable, and errors are hard to correct. Self-configuring = technologies rely largely on the good will of others, which is easier to = find during a pioneering phase. Arguably, we are beyond the pioneering = phase for IPv6. It's hard to argue that we're beyond the pioneering phase of IPv6 when = native IPv6 is still not widely available. The pushback was = predictable, for the very reasons you cite. But it's premature and = counterproductive to cave in to it. If pain associated with 6to4 = provides an additional incentive for ISPs to deploy native v6, and for = users to use native v6 when it becomes available, that's a Good Thing. = (Not that I want to cause them pain, but neither do I want the Internet = to be stuck with 6to4 and Teredo forever.) > I understand Keith's point of view, but it is probably time to start = progressively rolling back the transition technologies. 6to4 is the = weakest of these technologies. It does not traverse NAT, it does not = include configuration verification tests, and it uses asymmetric paths. = It makes sense to start the rollback with 6to4. The time to start rolling back the transition technologies is when v6 = support is available off the shelf. Because there is some pain = associated with them, there's a built in incentive to do so.=20 And I disagree that 6to4 is the weakest of the technologies. They all = have strengths and weaknesses. 6to4 is very widely implemented, is = automatically configurable, needs no central server, and routing is = near-optimal for 6to4-to-6to4 traffic. But there's a community learning = curve associated with using anycast addresses for relay routers. = Configured tunnels take a latency hit on every packet, no matter where = it's going. Teredo works through NATs (good), but also requires routing = packets through third party servers, with the corresponding implications = for latency, privacy, etc. And in practice, it's pretty much a = Microsoft-only solution - it doesn't ship with either Mac or Linux. (If we could have developed a universal best-of-breed transition = technology, I think we would have done so. But the solution space = really didn't permit that, so we ended up with a hodgepodge of different = tools that are applicable in different situations.) Keith From lorenzo@google.com Thu Jun 9 10:42:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB4B11E81BF for ; Thu, 9 Jun 2011 10:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nadFKb+5v-LP for ; Thu, 9 Jun 2011 10:42:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5123B11E81BE for ; Thu, 9 Jun 2011 10:42:39 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p59HgcRc031276 for ; Thu, 9 Jun 2011 10:42:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307641358; bh=T6MkxhKlW7q5q3R4HYlW74XmKl0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=nVB2nitlu06xCzQWERkduEGMRaOeCc3qjCDyO7ipvRFb3S2k+JqanNUS57L/nSm0G RW8AOxeLwr6G6cd5mjmDA== Received: from ywg4 (ywg4.prod.google.com [10.192.7.4]) by wpaz1.hot.corp.google.com with ESMTP id p59HexHY007343 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 9 Jun 2011 10:42:37 -0700 Received: by ywg4 with SMTP id 4so1173981ywg.24 for ; Thu, 09 Jun 2011 10:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TTa49wQJwHsNiTIedUP96nZM+KJ2gEy/spcn0oX02No=; b=uKkj3hzXdMt1OV2ZC/WkM/flBGGe0ZS3Q6FoCLKqc3t8AShokQu6nC7RMYKoHz474J AEGJguE3dOQVyX39bYuA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=SzPsvbQYIZhI0g212YycmV4NjqSyDHnY8u5ZAOe21VQ1z7heNlNHVZ6FCUof3L+b8W DChiFIXVpwDc+3kZ6IiA== Received: by 10.151.86.3 with SMTP id o3mr2376293ybl.150.1307641357160; Thu, 09 Jun 2011 10:42:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.95.20 with HTTP; Thu, 9 Jun 2011 10:42:17 -0700 (PDT) In-Reply-To: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 9 Jun 2011 10:42:17 -0700 Message-ID: To: Keith Moore Content-Type: multipart/alternative; boundary=000e0cd28fee96504804a54afa79 X-System-Of-Record: true Cc: IPv6 Operations Working Group , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 17:42:40 -0000 --000e0cd28fee96504804a54afa79 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 7, 2011 at 11:20 AM, Keith Moore wrote: > Indeed, that is one of its main virtues. 6to4 decouples application > deployment of v6 from network deployment of v6, and helps reduce the > "chicken or egg" problem. > No, it does not - in fact, it is the opposite. Geoff has presented data that shows that anycasted 6to4 as a connectivity mechanism has a failure rate of the order of 20-30%. We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure rate when connecting to dual-stack servers than Mac OS 10.6.5 - and the only change is to not use 6to4 by default. Search the list archives for details. So the existence of 6to4 is in itself a significant barrier for IPv6 deployment for server operators and content providers. And if you believe the access networks, the lack of IPv6 content is one of the most significant barriers to IPv6 deployment in access networks. Application developers should develop using manually configured tunnels, not 6to4. At least they don't have a 20% failure rate. --000e0cd28fee96504804a54afa79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 7, 2011 at 11:20 AM, Keith Moore <moore@netw= ork-heretics.com> wrote:
Indeed, that is one of its main virtues. =A06to4 decouple= s application deployment of v6 from network deployment of v6, and helps red= uce the "chicken or egg" problem.

No, it does not - in fact, it is the opposite.

Geoff has presented data that shows that anycasted 6to4 as a connectivity= mechanism has a failure rate of the order of 20-30%. We have data that cle= arly shows that Mac OS 10.6.4, which uses 6to4 by default, has a ~50x great= er failure rate when connecting to dual-stack servers than Mac OS 10.6.5 - = and the only change is to not use 6to4 by default. Search the list archives= for details.

So the existence of 6to4 is in itself a significant = barrier for IPv6 deployment for server operators and content providers. And= if you believe the access networks, the lack of IPv6 content is one of the= most significant barriers to IPv6 deployment in access networks.

Application developers should develop using manually co= nfigured tunnels, not 6to4. At least they don't have a 20% failure rate= .
--000e0cd28fee96504804a54afa79-- From moore@network-heretics.com Thu Jun 9 10:58:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6A211E81EC; Thu, 9 Jun 2011 10:58:01 -0700 (PDT) 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.361, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aPBmbfHALfe; Thu, 9 Jun 2011 10:58:00 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0DE11E8180; Thu, 9 Jun 2011 10:58:00 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id E9F5620733; Thu, 9 Jun 2011 13:57:59 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 09 Jun 2011 13:57:59 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=WYjxSYzdZEgOg/cG/lrjjYY+BFM=; b=o8nJeeNVk8ea4pvTDhpQSEg2WJohlci8gIb25W1UsaUE0o3zK0QLun7eHQQarFEeS0R1nbuKLAO4QRfYk1KjpSdxbm94SOzF/x/X5DGdZ6r3JjErdLc0gb8Gz9uDjwhN/2muSP/fk3rVPqtSivMXutzbyCj+3B93bwsVfR+DMJU= X-Sasl-enc: +VpHuf6FRZTW7vUwdzN35G5jJW5fTic3O/LCOFktQJk+ 1307642278 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 57514442D5F; Thu, 9 Jun 2011 13:57:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-24-770079235 From: Keith Moore In-Reply-To: Date: Thu, 9 Jun 2011 13:57:57 -0400 Message-Id: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Working Group , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 17:58:01 -0000 --Apple-Mail-24-770079235 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 9, 2011, at 1:42 PM, Lorenzo Colitti wrote: > On Tue, Jun 7, 2011 at 11:20 AM, Keith Moore = wrote: > Indeed, that is one of its main virtues. 6to4 decouples application = deployment of v6 from network deployment of v6, and helps reduce the = "chicken or egg" problem. >=20 > No, it does not - in fact, it is the opposite. >=20 > Geoff has presented data that shows that anycasted 6to4 as a = connectivity mechanism has a failure rate of the order of 20-30%. I don't dispute that data. I just disagree with the notion of = discouraging 6to4 in its entirety because of the current problems with = advertising 6to4 relay routers using anycast addresses. I suspect that the anycast issues will largely be sorted out before this = document can have much of an effect. But nevertheless, I don't have a = problem with discouraging this use of anycast. I think it was a noble = experiment, and we learned something valuable: Don't use anycast to = advertise a service that is provided by a wide range of players, at = least not without having some fairly clear guidelines about how to = monitor them and weed out the broken ones. > We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by = default, has a ~50x greater failure rate when connecting to dual-stack = servers than Mac OS 10.6.5 - and the only change is to not use 6to4 by = default. Search the list archives for details. Again, I have no problem with implementations disabling 6to4 by default. = Especially given the looming threat of LSN, I became convinced that it = was the right thing to do. > So the existence of 6to4 is in itself a significant barrier for IPv6 = deployment for server operators and content providers. non sequitur. Existing server operators and content providers can = easily provide 6to4 addresses for their servers and content, which will = be used in preference to native v6 addresses. > Application developers should develop using manually configured = tunnels, not 6to4. At least they don't have a 20% failure rate. How do you know? How do you even measure the failure rate of manually = configured tunnels in the aggregate? I don't think you can monitor that = kind of traffic the way you can 6to4, because the traffic patterns are = much more constrained. It's been awhile since I used manually = configured tunnels (from a well-known tunnel broker). But the one time = I did try them, 6to4 worked better overall - lower latency and lower = failure rate. Keith --Apple-Mail-24-770079235 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Tue, Jun 7, 2011 at 11:20 AM, Keith Moore <moore@network-heretics.com&= gt; wrote:
Indeed, that is one of its main virtues.  6to4 = decouples application deployment of v6 from network deployment of v6, = and helps reduce the "chicken or egg" = problem.

No, it does not - in fact, it is the = opposite.

Geoff has presented data that shows = that anycasted 6to4 as a connectivity mechanism has a failure rate of = the order of 20-30%.

I = don't dispute that data.  I just disagree with the notion of = discouraging 6to4 in its entirety because of the current problems with = advertising 6to4 relay routers using anycast = addresses.

I suspect that the anycast issues = will largely be sorted out before this document can have much of an = effect.  But nevertheless, I don't have a problem with discouraging = this use of anycast.  I think it was a noble experiment, and we = learned something valuable:  Don't use anycast to advertise a = service that is provided by a wide range of players, at least not = without having some fairly clear guidelines about how to monitor them = and weed out the broken ones.

We have data that clearly shows that Mac OS = 10.6.4, which uses 6to4 by default, has a ~50x greater failure rate when = connecting to dual-stack servers than Mac OS 10.6.5 - and the only = change is to not use 6to4 by default. Search the list archives for = details.

Again, I have no = problem with implementations disabling 6to4 by default.  Especially = given the looming threat of LSN, I became convinced that it was the = right thing to do.

So the existence of 6to4 is in itself a significant barrier = for IPv6 deployment for server operators and content = providers.

non sequitur. =   Existing server operators and content providers can easily = provide 6to4 addresses for their servers and content, which will be used = in preference to native v6 addresses.

Application developers should develop using manually configured = tunnels, not 6to4. At least they don't have a 20% failure = rate.

How do you know?  How do you even = measure the failure rate of manually configured tunnels in the = aggregate?  I don't think you can monitor that kind of traffic the = way you can 6to4, because the traffic patterns are much more = constrained.   It's been awhile since I used manually configured = tunnels (from a well-known tunnel broker).  But the one time I did = try them, 6to4 worked better overall - lower latency and lower failure = rate.

Keith

= --Apple-Mail-24-770079235-- From lorenzo@google.com Thu Jun 9 11:00:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BFC11E81E5 for ; Thu, 9 Jun 2011 11:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbGM8zbeHlaT for ; Thu, 9 Jun 2011 11:00:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id E553011E81EC for ; Thu, 9 Jun 2011 11:00:05 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p59I051a025565 for ; Thu, 9 Jun 2011 11:00:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307642405; bh=GGEIZvHkvdC1lTwVtd1ona/is/Y=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=dRUFuRCeGDYJVLojdU8MoeTvyywHaEajehE+j3nbIWsypMbbWPJJyw0ZWr+pJjX8+ 5vrVFK/ISDg8ObV/KpVTg== Received: from gxk7 (gxk7.prod.google.com [10.202.11.7]) by hpaq5.eem.corp.google.com with ESMTP id p59HxHxf008734 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 9 Jun 2011 11:00:03 -0700 Received: by gxk7 with SMTP id 7so1395817gxk.35 for ; Thu, 09 Jun 2011 11:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8aubcWvimXpHlG20i/IcdVljNEnI6GWfGWGL7dtVh08=; b=kmrIUr/x3jWpVby3SNzGP0gf0o45mt6FS08Nzr/wRFXUX0zs1T8IydmrJj6w8NFQTr +XrZcRFzqsgMrrdafB5w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=JJqR1LSha5illt6wpYAdRV1tNPSml5F8DenZL6GsPQNEmupjbPcbjkC3+xyibsXMoq RjcbypB9Md9h2QhP0WIg== Received: by 10.150.7.15 with SMTP id 15mr2184378ybg.378.1307642403106; Thu, 09 Jun 2011 11:00:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.95.20 with HTTP; Thu, 9 Jun 2011 10:59:42 -0700 (PDT) In-Reply-To: <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> From: Lorenzo Colitti Date: Thu, 9 Jun 2011 10:59:42 -0700 Message-ID: To: Keith Moore Content-Type: multipart/alternative; boundary=000e0cd28788ee2fb204a54b38c7 X-System-Of-Record: true Cc: "v6ops@ietf.org" , "ietf@ietf.org" Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 18:00:30 -0000 --000e0cd28788ee2fb204a54b38c7 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 7, 2011 at 3:47 PM, Keith Moore wrote: > Why are you trying to make life harder for developers of IPv6 applications? > There's no reason at all that an application developer should have to set > up a special-purpose network just to test an IPv6 application. > No, we're trying to make their lives easier, by suggesting they use something that actually *works*. > Realistic testing of applications needs to be done on real networks, or a > least an approximation to real networks. Testing IPv6 using 6to4 over > public IPv4 obviously isn't perfect, but it's a hell of a lot more realistic > than setting up a lab network and confining one's testing to that. > So use a tunnel broker. > You're missing something. I can connect directly from my mobile laptop to > a machine in my home network using 6to4. > Really? From where? On none of the networks my laptop connects to do I get a public IPv4 address. Some of them do give me have native IPv6 or manually-tunneled IPv6 though. We can disagree about the meaning of the word "widespread", but the > practical fact is that you can't expect people to give up something that > works for them until you can provide them something that works better *for > them. "Available to 50% of Internet service customers" is equivalent to a > very small percent probability of native connectivity being able to replace > 6to4 connectivity in a scenario where 6to4 is currently working. And the > more hosts involved, the smaller that probability is. * > You cannot claim that 6to4 is "working" when there is data that shows that it has a 20% failure rate. If we had that sort of connectivity in IPv4, we wouldn't have an Internet. > Existing "content providers" are not going to drive adoption of IPv6. > They're going to follow it. > Nope. Look at World IPv6 day. If you look at the list of participaints, I'd say that probably more than 10% of Internet content, either by bits or by query volume, is ready for IPv6 now. Our data shows that access is at 0.3%. So you could say that in fact content *is* driving adoption of IPv6. We just need to get unreliable tunneled connectivity out of the way so we can turn it on for real. > Web and email will be the last applications to migrate. > Um, no. See above. > WEG> Well, it'd be more harmful if there weren't alternatives. > > > There aren't any good ones. Teredo and configured tunnels are worse in > many ways; though they each have their use cases. > Actually, configured tunnels are much better. They have a much lower failure rate and lower latency. We published data that shows the latency impact in our PAM 2009 paper. Regards, Lorenzo --000e0cd28788ee2fb204a54b38c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 7, 2011 at 3:47 PM, Keith Moore <moore@network-heretics.com> wrote:
Why are you trying to make life ha= rder for developers of IPv6 applications? =A0There's no reason at all t= hat an application developer should have to set up a special-purpose networ= k just to test an IPv6 application.=A0

No, we're trying to make their l= ives easier, by suggesting they use something that actually *works*.
<= div>=A0
Realistic testing of applicat= ions needs to be done on real networks, or a least an approximation to real= networks. =A0Testing IPv6 using 6to4 over public IPv4 obviously isn't = perfect, but it's a hell of a lot more realistic than setting up a lab = network and confining one's testing to that.

So use a tunnel broker.
<= div>=A0
You're missing something. =A0 I can connect directly from my mobil= e laptop to a machine in my home network using 6to4.

Really? From where? On none of the networks my laptop= connects to do I get a public IPv4 address. Some of them do give me have n= ative IPv6 or manually-tunneled IPv6 though.

We can disagree about the meaning of the word "widespread&= quot;, but the practical fact is that you can't expect people to give u= p something that works for them until you can provide them something that w= orks better for them. =A0"Availab= le to 50% of Internet service customers" is equivalent to a very small= percent probability of native connectivity being able to replace 6to4 conn= ectivity in a scenario where 6to4 is currently working. =A0And the more hos= ts involved, the smaller that probability is.=A0

You cannot claim that 6to4 is "= working" when there is data that shows that it has a 20% failure rate.= If we had that sort of connectivity in IPv4, we wouldn't have an Inter= net.
=A0
Existing "content providers" are not going to drive ad= option of IPv6. =A0 They're going to follow it.

Nope. Look at World IPv6 day. If you= look at the list of participaints, I'd say that probably more than 10%= of Internet content, either by bits or by query volume, is ready for IPv6 = now. Our data shows that access is at 0.3%. So you could say that in fact c= ontent *is* driving adoption of IPv6. We just need to get unreliable tunnel= ed connectivity out of the way so we can turn it on for real.
=A0
=A0Web and email will be the last applications to migrate.

Um, no. See above.
WEG> Well, it'd be more harmful if there weren't alternativ= es.

There= aren't any good ones. =A0Teredo and configured tunnels are worse in ma= ny ways; though they each have their use cases. =A0=A0

Actually, configured tunnels a= re much better. They have a much lower failure rate and lower latency. We p= ublished data that shows the latency impact in our PAM 2009 paper.

Regards,
Lorenzo
--000e0cd28788ee2fb204a54b38c7-- From jhw@apple.com Thu Jun 9 11:01:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5643E11E8205; Thu, 9 Jun 2011 11:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DJ7A1+e7dvD; Thu, 9 Jun 2011 11:01:24 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 353A911E8162; Thu, 9 Jun 2011 11:01:22 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LMJ007VQBBAOH50@mail-out.apple.com>; Thu, 09 Jun 2011 11:01:21 -0700 (PDT) X-AuditID: 11807137-b7cd4ae000003108-9b-4df10a710113 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id C9.3E.12552.17A01FD4; Thu, 09 Jun 2011 11:01:21 -0700 (PDT) Received: from event-10-2-63-213.venue.apple.com (unknown [192.42.249.191]) by kencur.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LMJ00J3EBE8V210@kencur.apple.com>; Thu, 09 Jun 2011 11:01:20 -0700 (PDT) From: james woodyatt In-reply-to: Date: Thu, 09 Jun 2011 11:01:22 -0700 Message-id: <056CE2B5-5DE5-4B0D-B38B-569C011B2733@apple.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> To: Keith Moore X-Mailer: Apple Mail (2.1237.1) X-Brightmail-Tracker: AAAAAA== Cc: "v6ops@ietf.org WG" , ietf@ietf.org Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 18:01:25 -0000 On Jun 9, 2011, at 7:37 AM, Keith Moore wrote: > > Clearly the intent of this draft and protocol action are to discourage use of 6to4, particularly in new implementations. You can't discourage use of 6to4 in new implementations without harming people who are already using it and depending on it. After it became clear to me that IETF will not be issuing a phase-out plan for 6to4, I recommended to all the relevant product managers at Apple that we should continue supporting 6to4 in new implementations for the foreseeable future (despite the non-RFC2119 'not recommended' line in section 1). I don't see why this draft should discourage anyone from continuing to support 6to4, which as you point out is a *uniquely* useful protocol that people depend on and find *irreplaceable*. Reclassifying it as Historic simply allows IETF working groups to operate on the fiction that 6to4 will eventually disappear someday in the indefinite and vaguely hopeful future. While I don't think that self-delusion will be a good thing for IETF in the long run, I have a hard time getting too bummed out about it. Pragmatism will find its way into deliberations. Yes, I think this draft is a pointless waste of time. The reason I support publishing it, however, is that I disagree with your assessment of the harm it could do. Also, it enjoys widespread support in the V6OPS working group and the opposition, while vocal, seems quite small. That looks like rough consensus to me, and if I can help get it off our agenda sooner by supporting it rather than opposing it, then I say let's print it. I confidently predict the reclassification to Historic will be roundly ignored not just by Apple product engineering but by the entire industry. We're smart enough to recognize that we're not the target audience for the RFC. The draft that matters is the companion advisory draft. It would be nice if the 6to4-to-historic draft could be spiked so as not to distract from its companion, but I don't see that as a likely outcome. Alas and alack. -- james woodyatt member of technical staff, core os networking From lorenzo@google.com Thu Jun 9 11:11:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1586E11E8162 for ; Thu, 9 Jun 2011 11:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VonhNPC9ZkCH for ; Thu, 9 Jun 2011 11:10:53 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id DF6CD11E8102 for ; Thu, 9 Jun 2011 11:10:50 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p59IAccW004080 for ; Thu, 9 Jun 2011 11:10:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307643038; bh=Td5nNzknJeZhpOaY7uSrKSDeaPw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=haJKokUQnIWLVxowhSct5TEcb39BMlhgyFwItMoBmxudMb/CiYKYv9jpaOBmFsglU nHvCOBclBvZiVFmWo7byQ== Received: from yxm8 (yxm8.prod.google.com [10.190.4.8]) by wpaz17.hot.corp.google.com with ESMTP id p59IAad9032211 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 9 Jun 2011 11:10:37 -0700 Received: by yxm8 with SMTP id 8so716222yxm.9 for ; Thu, 09 Jun 2011 11:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=T/0mwUxCnSFBcwdprxowvsMq/uvHysIXYXl2nkndiYA=; b=hqeOSIE1aAYw58m3vxWm4qmKwFzi+U3Eu05EZ6nnG2Xg9cwn/PQrZynE6BnPJdAyAF njZmeLtnhk+DbeiU9nlg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=F/9LoErnd0Oq4ZU+ebG6HnmksVWt0LQtH77Tgi4AG+kqLdSI7kNfZUnYizAk2U3BVI BU36rDe3UO4DeB4OangA== Received: by 10.150.195.18 with SMTP id s18mr2211619ybf.207.1307643037121; Thu, 09 Jun 2011 11:10:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.95.20 with HTTP; Thu, 9 Jun 2011 11:10:17 -0700 (PDT) In-Reply-To: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB0690A2B5@PRVPEXVS04.corp.twcable.com> From: Lorenzo Colitti Date: Thu, 9 Jun 2011 11:10:17 -0700 Message-ID: To: Keith Moore Content-Type: multipart/alternative; boundary=000e0cd4d83cb87ba304a54b5eb5 X-System-Of-Record: true Cc: "v6ops@ietf.org" , "ietf@ietf.org" Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 18:11:24 -0000 --000e0cd4d83cb87ba304a54b5eb5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 8, 2011 at 1:19 PM, Keith Moore wrote: > Again, 40-something percent of the IPv6 traffic that is observed on the net > today uses 6to4. > Please point at the data behind that assertion. In many cases in the past, such assertions have comes from networks that do not have the hardware capabilities to monitor native IPv6 traffic. I remember one case at the RIPE meeting where someone from AMS-IX observed about one of these presentations, "I have more native IPv6 traffic on my exchange point than you have observed in the entire Internet. How is that possible?" Needless to say, that presentation did not go well. Look at http://www.google.com/intl/en/ipv6/statistics/ That obviously does not see peer-to-peer traffic, but it does see IPv6 web clients, and just under 90% of those are native. The evidence is that people are using it. You're trying to subject it to > test cases that are largely meaningless - because in those cases IPv6 (of > any kind) provides no marginal value in the near term. > So far, you have provided solid evidence that *you* use it, but not solid evidence that "people" are using it. Can you point to that evidence? > Almost all usage of IPv6 today is in spite of ISPs. For that matter, a > great many successful IPv4 applications today are deployed in spite of ISPs. > Again, ISPs in general have let us down, and 6to4 and Teredo are carrying > ~90% of IPv6 traffic. ISPs are not in a good position to demand that 6to4 > be deprecated. > Nope. As before, 90% of IPv6 is native, and it comes from a small number of large deployments. Maybe your ISP doesn't support it, but other ISPs do. > It's not one versus the other. 6to4 is helping to promote ubiquitous > IPv6. > No, it is a barrier to ubiquitous IPv6 adoption. --000e0cd4d83cb87ba304a54b5eb5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 8, 2011 at 1:19 PM, Keith Moore <moore@netwo= rk-heretics.com> wrote:
Again, 40-something percent of the= IPv6 traffic that is observed on the net today uses 6to4.

Please point at the data behind that assertion.= In many cases in the past, such assertions have comes from networks that d= o not have the hardware capabilities to monitor native IPv6 traffic. I reme= mber one case at the RIPE meeting where someone from AMS-IX observed about = one of these presentations, "I have more native IPv6 traffic on my exc= hange point than you have observed in the entire Internet. How is that poss= ible?" Needless to say, that presentation did not go well.

Look at http://www.google.com/intl/en/ipv6/statistics/ That obvious= ly does not see peer-to-peer traffic, but it does see IPv6 web clients, and= just under 90% of those are native.

The evidence is that people are using it. =A0You're trying= to subject it to test cases that are largely meaningless - because in thos= e cases IPv6 (of any kind) provides no marginal value in the near term.

So far, you have provided solid evid= ence that *you* use it, but not solid evidence that "people" are = using it. Can you point to that evidence?
=A0
Almost all usage= of IPv6 today is in spite of ISPs. =A0 For that matter, a great many succe= ssful IPv4 applications today are deployed in spite of ISPs. =A0Again, ISPs= in general have let us down, and 6to4 and Teredo are carrying ~90% of IPv6= traffic. =A0 ISPs are not in a good position to demand that 6to4 be deprec= ated. =A0

Nope. As before, 90% of IPv6 i= s native, and it comes from a small number of large deployments. Maybe your= ISP doesn't support it, but other ISPs do.
=A0
It's not one versus the other.= =A0 6to4 is helping to promote ubiquitous IPv6.

No, it is a barrier to ubiquitous IPv6 adoption.
--000e0cd4d83cb87ba304a54b5eb5-- From lorenzo@google.com Thu Jun 9 11:20:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178D511E8162 for ; Thu, 9 Jun 2011 11:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REqec+iAeptc for ; Thu, 9 Jun 2011 11:20:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1C20011E8130 for ; Thu, 9 Jun 2011 11:20:24 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p59IKN9m023538 for ; Thu, 9 Jun 2011 11:20:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307643624; bh=1VesNEVkML4j63VbRAi5728Ppv0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CeqZPwu+YpQkjs9CbOim3bShiHWEdvTt+5IwyS1Erx+Y87593E7c3c2ahvF6xFgxG 4htw3lxQFTtjZ129OXe2g== Received: from gxk1 (gxk1.prod.google.com [10.202.11.1]) by hpaq5.eem.corp.google.com with ESMTP id p59IIjOH000456 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 9 Jun 2011 11:20:22 -0700 Received: by gxk1 with SMTP id 1so1134219gxk.38 for ; Thu, 09 Jun 2011 11:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=br6F0TJ2UVxjNzX64Aity0SMmDbtqwSnX3X6/QUO2oQ=; b=h/GqfzTe8XlNo9N5DnszA7nbemEIOh1yCFE08Vp+twWHvIexTStrzdCqC7dd5qxJL+ ALteWlTjZr71mR1lc01A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=mHbY5Aqu5z7CJayKJY8Qt6ViW3iNCL91o9M2yQvY0P13xQ+DHG3WbOp2rMwao0wdiw UagyMtzeYz7nK/e7TV8g== Received: by 10.151.86.3 with SMTP id o3mr2419927ybl.150.1307643622102; Thu, 09 Jun 2011 11:20:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.95.20 with HTTP; Thu, 9 Jun 2011 11:20:02 -0700 (PDT) In-Reply-To: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 9 Jun 2011 11:20:02 -0700 Message-ID: To: Keith Moore Content-Type: multipart/alternative; boundary=000e0cd28fee9695e404a54b81e8 X-System-Of-Record: true Cc: IPv6 Operations Working Group , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 18:20:26 -0000 --000e0cd28fee9695e404a54b81e8 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore wrote: > So the existence of 6to4 is in itself a significant barrier for IPv6 > deployment for server operators and content providers. > > non sequitur. Existing server operators and content providers can easily > provide 6to4 addresses for their servers and content, which will be used in > preference to native v6 addresses. > No. According to Geoff's data, one of the main reasons 6to4 fails is a firewall that blocks IPv4 protocol 41 traffic. Even if content providers published 6to4 addresses, those connections would still fail. > Application developers should develop using manually configured tunnels, > not 6to4. At least they don't have a 20% failure rate. > > How do you know? How do you even measure the failure rate of manually > configured tunnels in the aggregate? > In a similar way as Geoff measured 6to4 - looking at SYNs. I suspect that the answer will be that much fewer users have configured tunnels than 6to4, and that the failure rate is much lower. > I don't think you can monitor that kind of traffic the way you can 6to4, > because the traffic patterns are much more constrained. It's been awhile > since I used manually configured tunnels (from a well-known tunnel broker). > But the one time I did try them, 6to4 worked better overall - lower latency > and lower failure rate. > Please try again. You will be pleasantly surprised. --000e0cd28fee9695e404a54b81e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore <moore@netw= ork-heretics.com> wrote:
So the existence of 6to4 is = in itself a significant barrier for IPv6 deployment for server operators an= d content providers.
non sequitur. =A0 Existing server operators = and content providers can easily provide 6to4 addresses for their servers a= nd content, which will be used in preference to native v6 addresses.

No. According to Geoff's data, o= ne of the main reasons 6to4 fails is a firewall that blocks IPv4 protocol 4= 1 traffic. Even if content providers published 6to4 addresses, those connec= tions would still fail.
=A0
Application developers should develop using manually configured tunnel= s, not 6to4. At least they don't have a 20% failure rate.
How do you know? =A0How do you even measu= re the failure rate of manually configured tunnels in the aggregate?

In a similar way as Geoff measured 6= to4 - looking at SYNs. I suspect that the answer will be that much fewer us= ers have configured tunnels than 6to4, and that the failure rate is much lo= wer.
=A0
=A0I don't think you can monitor that kind of traffic the = way you can 6to4, because the traffic patterns are much more constrained. = =A0 It's been awhile since I used manually configured tunnels (from a w= ell-known tunnel broker). =A0But the one time I did try them, 6to4 worked b= etter overall - lower latency and lower failure rate.

Please try again. You will be pleasa= ntly surprised.=A0
--000e0cd28fee9695e404a54b81e8-- From moore@network-heretics.com Thu Jun 9 11:37:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E0B11E8126; Thu, 9 Jun 2011 11:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDO3oSJ7MoAL; Thu, 9 Jun 2011 11:37:43 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id E0D1811E8106; Thu, 9 Jun 2011 11:37:42 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 8D7A320D4F; Thu, 9 Jun 2011 14:37:42 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 09 Jun 2011 14:37:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=HHlX9GldpM7wHuM3Xub7w7FjAMk=; b=pdT5Fc2xmPtkQCZCD12d88PTJT2s+P5lSvDwwgTmEyINCH/LZgMAebgjH2voPl8488TQdGTH/R1ibUHSSiSjLKsK9IMwWO+AWL0HOcgd6PeeH/32qxkQY0qfKDMEH4A2CM8r5m6QMx6Is/MrspY9yUIj/6tQxNai5erBYaV4iD4= X-Sasl-enc: CgmxgZ8cG0Ub9WfkCnakyJKqsKGDFSw4CbD0pwQUZalo 1307644661 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id EF61E445597; Thu, 9 Jun 2011 14:37:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-25-772461679 From: Keith Moore In-Reply-To: Date: Thu, 9 Jun 2011 14:37:39 -0400 Message-Id: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Working Group , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 18:37:44 -0000 --Apple-Mail-25-772461679 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 9, 2011, at 2:20 PM, Lorenzo Colitti wrote: > On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore = wrote: >> So the existence of 6to4 is in itself a significant barrier for IPv6 = deployment for server operators and content providers. > non sequitur. Existing server operators and content providers can = easily provide 6to4 addresses for their servers and content, which will = be used in preference to native v6 addresses. >=20 > No. According to Geoff's data, one of the main reasons 6to4 fails is a = firewall that blocks IPv4 protocol 41 traffic. Even if content providers = published 6to4 addresses, those connections would still fail. I suppose we should just tunnel the whole IPv6 network over IPv4 + HTTP = then. Seriously, the argument that 6to4 should be trashed because ISPs are = blocking tunnels has the flavor of "don't solve the problem, but rather, = stamp out the solution".=20 (And of course if the ISPs block protocol 41, that will also kill = configured tunnels that happen to transit their networks. The overall = failure rate will be the same, but the granularity of failure will be = higher for the configured tunnels.) >> Application developers should develop using manually configured = tunnels, not 6to4. At least they don't have a 20% failure rate. >=20 > How do you know? How do you even measure the failure rate of manually = configured tunnels in the aggregate? >=20 > In a similar way as Geoff measured 6to4 - looking at SYNs. =46rom where? Again, the tunnels aren't taking the variety of paths = that 6to4 connections are. It's that variety that makes measurements = such as Geoff's at all useful - it's what lets you at least believe that = the measurements made at a few points are representative of the whole. =20 > I don't think you can monitor that kind of traffic the way you can = 6to4, because the traffic patterns are much more constrained. It's = been awhile since I used manually configured tunnels (from a well-known = tunnel broker). But the one time I did try them, 6to4 worked better = overall - lower latency and lower failure rate. >=20 > Please try again. You will be pleasantly surprised.=20 A few months ago I was trying to set one up, but I ran out of time. = I'm really busy these days, and it's nowhere nearly as easy to set up a = configured tunnel as it is to set up 6to4. Keith --Apple-Mail-25-772461679 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore <moore@network-heretics.com&= gt; wrote:
So the existence of = 6to4 is in itself a significant barrier for IPv6 deployment for server = operators and content providers.
non sequitur.   Existing server = operators and content providers can easily provide 6to4 addresses for = their servers and content, which will be used in preference to native v6 = addresses.

No. According to Geoff's data, = one of the main reasons 6to4 fails is a firewall that blocks IPv4 = protocol 41 traffic. Even if content providers published 6to4 addresses, = those connections would still = fail.

I suppose we should just = tunnel the whole IPv6 network over IPv4 + HTTP = then.

Seriously, the argument that 6to4 should = be trashed because ISPs are blocking tunnels has the flavor of "don't = solve the problem, but rather, stamp out the = solution". 

(And of course if the ISPs = block protocol 41, that will also kill configured tunnels that happen to = transit their networks.  The overall failure rate will be the same, = but the granularity of failure will be higher for the configured = tunnels.)

Application developers should develop using manually configured = tunnels, not 6to4. At least they don't have a 20% failure = rate.
How do you know? =  How do you even measure the failure rate of manually configured = tunnels in the aggregate?

In a similar way as Geoff = measured 6to4 - looking at = SYNs.

=46rom where?   = Again, the tunnels aren't taking the variety of paths that 6to4 = connections are.  It's that variety that makes measurements such as = Geoff's at all useful - it's what lets you at least believe that the = measurements made at a few points are representative of the = whole.
 
=  I don't think you can monitor that kind of traffic the way you can = 6to4, because the traffic patterns are much more constrained.   = It's been awhile since I used manually configured tunnels (from a = well-known tunnel broker).  But the one time I did try them, 6to4 = worked better overall - lower latency and lower failure rate.

Please try again. You will be = pleasantly surprised. 

A few months ago I was trying to set one up, = but I ran out of time.   I'm really busy these days, and it's = nowhere nearly as easy to set up a configured tunnel as it is to set up = 6to4.

Keith

= --Apple-Mail-25-772461679-- From lorenzo@google.com Thu Jun 9 11:46:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB9B11E8089 for ; Thu, 9 Jun 2011 11:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n54IEmK9EM9u for ; Thu, 9 Jun 2011 11:46:17 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id D8E5F11E80FE for ; Thu, 9 Jun 2011 11:46:16 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p59IkFdB002237 for ; Thu, 9 Jun 2011 11:46:15 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307645175; bh=2d8jA+tnkAxaFNA0UFhm/qtqx9A=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=patYUy5mgXnVkCe22He70lU+y9fhkLC0AP+ZaX7TkyN2kuPnAbZudtY3Z1lZhtKgA 8g9v6WR0qj5Q56wQkzvog== Received: from ywk9 (ywk9.prod.google.com [10.192.11.9]) by hpaq12.eem.corp.google.com with ESMTP id p59Iiwrw026073 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 9 Jun 2011 11:46:14 -0700 Received: by ywk9 with SMTP id 9so1395491ywk.7 for ; Thu, 09 Jun 2011 11:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yDkAjAygetx1YZoAXnJH4TxFkKVgKswkNI0Uqc122Hg=; b=tnhCNo972Pl0Ji4snwub+5Y14F5v+lj98Y3RnC35aGY4xcVxrM7F4/8poZjij+R7Nz ZhgjJXw7N6mc2EjUzsIQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=BGxgIbkuwROW/5zvOQjXaEmDkhLCbMt7iLz0I//yTMUqLPRV8OPGHluqxN577yAFWG 46XI/t5oqBPQI9mLLddQ== Received: by 10.150.7.15 with SMTP id 15mr2232992ybg.378.1307645174110; Thu, 09 Jun 2011 11:46:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.95.20 with HTTP; Thu, 9 Jun 2011 11:45:54 -0700 (PDT) In-Reply-To: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 9 Jun 2011 11:45:54 -0700 Message-ID: To: Keith Moore Content-Type: multipart/alternative; boundary=000e0cd28788185ae104a54bde25 X-System-Of-Record: true Cc: IPv6 Operations Working Group , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 18:46:20 -0000 --000e0cd28788185ae104a54bde25 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 9, 2011 at 11:37 AM, Keith Moore wrote: > I suppose we should just tunnel the whole IPv6 network over IPv4 + HTTP > then. > > Seriously, the argument that 6to4 should be trashed because ISPs are > blocking tunnels has the flavor of "don't solve the problem, but rather, > stamp out the solution". > Actually, this mostly happens in enterprise networks and universities. I don't see why they would want to change this compared to, say, actually deploying native IPv6. In a similar way as Geoff measured 6to4 - looking at SYNs. > > > From where? Again, the tunnels aren't taking the variety of paths that > 6to4 connections are. It's that variety that makes measurements such as > Geoff's at all useful - it's what lets you at least believe that the > measurements made at a few points are representative of the whole. > >From the same place that he ran the 6to4 measurements from? > A few months ago I was trying to set one up, but I ran out of time. I'm > really busy these days, and it's nowhere nearly as easy to set up a > configured tunnel as it is to set up 6to4. > Go to http://tunnelbroker.net/ . I'm willing to bet that it will take a lot less time than you have spent writing email on this thread. :-) --000e0cd28788185ae104a54bde25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 9, 2011 at 11:37 AM, Keith Moore <moore@netw= ork-heretics.com> wrote:
I suppose w= e should just tunnel the whole IPv6 network over IPv4 + HTTP then.

Seriously, the argument that 6to4 should be tr= ashed because ISPs are blocking tunnels has the flavor of "don't s= olve the problem, but rather, stamp out the solution".=A0

Actually, this mostly happens in ent= erprise networks and universities. I don't see why they would want to c= hange this compared to, say, actually deploying native IPv6.

In a similar way as Geoff measured 6to4 - looking at SYNs.

From where? =A0 Again, the tunnels aren&#= 39;t taking the variety of paths that 6to4 connections are. =A0It's tha= t variety that makes measurements such as Geoff's at all useful - it= 9;s what lets you at least believe that the measurements made at a few poin= ts are representative of the whole.

From the same place that he ra= n the 6to4 measurements from?
=A0
A few month= s ago I was trying to set one up, but I ran out of time. =A0 I'm really= busy these days, and it's nowhere nearly as easy to set up a configure= d tunnel as it is to set up 6to4.

Go to http://tunnelbroker.net/ . I'm willing to bet th= at it will take a lot less time than you have spent writing email on this t= hread. :-)
--000e0cd28788185ae104a54bde25-- From moore@network-heretics.com Thu Jun 9 11:53:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F8C11E80FE; Thu, 9 Jun 2011 11:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OozQLMkgw3NU; Thu, 9 Jun 2011 11:53:22 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id A78A611E8089; Thu, 9 Jun 2011 11:53:22 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 5608C209C8; Thu, 9 Jun 2011 14:53:22 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 09 Jun 2011 14:53:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=0LlyWP1/G2CgRG9r57vaAAxX6wg=; b=Z5zvSazZpdE8G4dIsS5ZXswIaAKgreWRsWQe/KUS8CbRONdxr10J5a08tcipJP9FcQCXlVJM3BJrTLJNGZnWyffHyNyCpWkPpIks1N5yW5ij9CoUrEI8u0kQrLKJTg42LmGHgSp7HFvSlTs1eBCU/3q/A8vdhA+0rrif4PXAz2U= X-Sasl-enc: y1L8I6EHE1AbF3KhTL46iAPRLaHY3iNk+2bQYHLRrhaA 1307645601 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id D1CF244046C; Thu, 9 Jun 2011 14:53:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-26-773401850 From: Keith Moore In-Reply-To: Date: Thu, 9 Jun 2011 14:53:19 -0400 Message-Id: <0AFB3478-E7AD-41B7-A1E7-88479D37BE93@network-heretics.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Working Group , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 18:53:23 -0000 --Apple-Mail-26-773401850 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 9, 2011, at 2:45 PM, Lorenzo Colitti wrote: > On Thu, Jun 9, 2011 at 11:37 AM, Keith Moore = wrote: > I suppose we should just tunnel the whole IPv6 network over IPv4 + = HTTP then. >=20 > Seriously, the argument that 6to4 should be trashed because ISPs are = blocking tunnels has the flavor of "don't solve the problem, but rather, = stamp out the solution".=20 >=20 > Actually, this mostly happens in enterprise networks and universities. = I don't see why they would want to change this compared to, say, = actually deploying native IPv6. Well if an enterprise network wants to firewall certain kinds of = traffic, that's its own business. The fact that some enterprises = firewall ip-over-ip tunnels is not a justification for IETF trashing one = particular kind of ip tunnel. >> In a similar way as Geoff measured 6to4 - looking at SYNs. >=20 > =46rom where? Again, the tunnels aren't taking the variety of paths = that 6to4 connections are. It's that variety that makes measurements = such as Geoff's at all useful - it's what lets you at least believe that = the measurements made at a few points are representative of the whole. >=20 > =46rom the same place that he ran the 6to4 measurements from? See above. It's not a valid measurement. Or the measurement is fine, = but comparisons between configured tunnels and 6to4 on the basis of such = measurements are not valid. =20 > A few months ago I was trying to set one up, but I ran out of time. = I'm really busy these days, and it's nowhere nearly as easy to set up a = configured tunnel as it is to set up 6to4. >=20 > Go to http://tunnelbroker.net/ . I'm willing to bet that it will take = a lot less time than you have spent writing email on this thread. :-) That's who I was using before. Keith --Apple-Mail-26-773401850 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jun 9, 2011, at 2:45 PM, Lorenzo Colitti wrote:

On Thu, Jun 9, 2011 at 11:37 AM, Keith Moore <moore@network-heretics.com> wrote:
I suppose we should just tunnel the whole IPv6 network over IPv4 + HTTP then.

Seriously, the argument that 6to4 should be trashed because ISPs are blocking tunnels has the flavor of "don't solve the problem, but rather, stamp out the solution". 

Actually, this mostly happens in enterprise networks and universities. I don't see why they would want to change this compared to, say, actually deploying native IPv6.

Well if an enterprise network wants to firewall certain kinds of traffic, that's its own business.  The fact that some enterprises firewall ip-over-ip tunnels is not a justification for IETF trashing one particular kind of ip tunnel.

In a similar way as Geoff measured 6to4 - looking at SYNs.

From where?   Again, the tunnels aren't taking the variety of paths that 6to4 connections are.  It's that variety that makes measurements such as Geoff's at all useful - it's what lets you at least believe that the measurements made at a few points are representative of the whole.

From the same place that he ran the 6to4 measurements from?

See above.  It's not a valid measurement.   Or the measurement is fine, but comparisons between configured tunnels and 6to4 on the basis of such measurements are not valid.
 
A few months ago I was trying to set one up, but I ran out of time.   I'm really busy these days, and it's nowhere nearly as easy to set up a configured tunnel as it is to set up 6to4.

Go to http://tunnelbroker.net/ . I'm willing to bet that it will take a lot less time than you have spent writing email on this thread. :-)

That's who I was using before.

Keith

--Apple-Mail-26-773401850-- From brian.e.carpenter@gmail.com Thu Jun 9 12:01:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CB11F0C5D; Thu, 9 Jun 2011 12:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVdJXJKV4MXM; Thu, 9 Jun 2011 12:01:49 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE361F0C64; Thu, 9 Jun 2011 12:01:11 -0700 (PDT) Received: by fxm15 with SMTP id 15so1362674fxm.31 for ; Thu, 09 Jun 2011 12:01:11 -0700 (PDT) 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=U9hn4RpC0/pc8TTWX/ov5ZUz0Mp+9axMFUIMeH5eDek=; b=bSp89EAED+fuq5nR1TuVSW5jjoejfEwTG9t+IDA5GRNqN0+EQlkMerFJn44vtD9t2+ MLP+VJmwc0Mkx9epNv/Y35KreWa9LKEA+1sSCFUOHQmOlm/qS3SKiNAdE/Bb3lkKj1GB 2XKEg/ozCQ+XPqUplBOApGVPVd895wrbMJfL0= 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=u+aPA208nMw2eW6cIKeJHzaZVn1fiwSAaty8bDRUqvzngfSMgDb8ple8/YLWnuKMsI oERTTY1b6R91N3CvkTx6w7//OZr0uHCmCymIHsildBQVYXrygm0ubGSK9kIitomm7ZS1 KKmPxUGxmTBrKMbDehZQ4g/OvvG5DPjmcn+SA= Received: by 10.223.102.131 with SMTP id g3mr1154816fao.68.1307646069483; Thu, 09 Jun 2011 12:01:09 -0700 (PDT) Received: from [10.255.25.89] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id g7sm769891fac.15.2011.06.09.12.01.06 (version=SSLv3 cipher=OTHER); Thu, 09 Jun 2011 12:01:08 -0700 (PDT) Message-ID: <4DF1186E.7080902@gmail.com> Date: Fri, 10 Jun 2011 07:01:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Working Group , Keith Moore , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 19:01:50 -0000 Hi Lorenzo, On 2011-06-10 06:20, Lorenzo Colitti wrote: > On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore wrote: > >> So the existence of 6to4 is in itself a significant barrier for IPv6 >> deployment for server operators and content providers. >> >> non sequitur. Existing server operators and content providers can easily >> provide 6to4 addresses for their servers and content, which will be used in >> preference to native v6 addresses. >> > > No. According to Geoff's data, one of the main reasons 6to4 fails is a > firewall that blocks IPv4 protocol 41 traffic. Even if content providers > published 6to4 addresses, those connections would still fail. To be clear, that statistic applies to clients whose SYN packet reaches the server, but who never respond to SYN/ACK. It's a presumption that the problem is Protocol 41 filtering - probably correct, but there are other possible causes. Also, we have no possible way of knowing how many clients send SYN packets towards a 6to4 anycast relay, but those packets are blackholed and never reach the intended server. From the client's viewpoint, this also looks like a missing SYN/ACK, leading to retries and eventual fallback to IPv4. In other words, the real failure rate may be much worse than Geoff reports, but we have no way of measuring it. > > >> Application developers should develop using manually configured tunnels, >> not 6to4. At least they don't have a 20% failure rate. >> >> How do you know? How do you even measure the failure rate of manually >> configured tunnels in the aggregate? >> > > In a similar way as Geoff measured 6to4 - looking at SYNs. I suspect that > the answer will be that much fewer users have configured tunnels than 6to4, > and that the failure rate is much lower. Er, I'm currently on 2001:388:f000::xxxx Do you have an algorithm that will tell you whether that is native or a configured tunnel? Brian > > >> I don't think you can monitor that kind of traffic the way you can 6to4, >> because the traffic patterns are much more constrained. It's been awhile >> since I used manually configured tunnels (from a well-known tunnel broker). >> But the one time I did try them, 6to4 worked better overall - lower latency >> and lower failure rate. >> > > Please try again. You will be pleasantly surprised. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Thu Jun 9 12:04:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC85411E8213 for ; Thu, 9 Jun 2011 12:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnMnW-srtkzj for ; Thu, 9 Jun 2011 12:04:19 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id F10DF11E8199 for ; Thu, 9 Jun 2011 12:04:18 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p59J4HCS004156 for ; Thu, 9 Jun 2011 12:04:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307646258; bh=vceBpKhIZ/wiky+RonlHf55viM8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=RV4AMYrMFj8oNuOMmt2vVTxEplOO+0AKli1hU5apsx80dvVsYG00/tuuPmif2b82G i5lQYfEqHLk16Yjw56CPA== Received: from yxh35 (yxh35.prod.google.com [10.190.2.227]) by kpbe13.cbf.corp.google.com with ESMTP id p59J4FRq017464 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 9 Jun 2011 12:04:16 -0700 Received: by yxh35 with SMTP id 35so870700yxh.5 for ; Thu, 09 Jun 2011 12:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2YDh8vN1YHly0VfHteGcU6qgSouyrkrpxLSnsTtn3wU=; b=QW0ktBOXMg+gGoqZ1Kv3LNXmkXMEV/YNQ+MbCvPeP/QQ0APe89DdQ0bFLHtXPQFJfe z2qjufO6VONvlelPr5Wg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=kIQJqe7AcnNrKg8igpU0ZQ2xNnuQudV8TWrAaGnHQ5nWPAEZdopZ3tvoCrsnDuxaJi zU5NymZBnlDXjnRjp7AA== Received: by 10.151.86.3 with SMTP id o3mr2469788ybl.150.1307646255347; Thu, 09 Jun 2011 12:04:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.95.20 with HTTP; Thu, 9 Jun 2011 12:03:55 -0700 (PDT) In-Reply-To: <4DF1186E.7080902@gmail.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <4DF1186E.7080902@gmail.com> From: Lorenzo Colitti Date: Thu, 9 Jun 2011 12:03:55 -0700 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=000e0cd28fee8ab81d04a54c1e60 X-System-Of-Record: true Cc: IPv6 Operations Working Group , Keith Moore , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 19:04:19 -0000 --000e0cd28fee8ab81d04a54c1e60 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 9, 2011 at 12:01 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > In a similar way as Geoff measured 6to4 - looking at SYNs. I suspect that > > the answer will be that much fewer users have configured tunnels than > 6to4, > > and that the failure rate is much lower. > > Er, I'm currently on 2001:388:f000::xxxx > Do you have an algorithm that will tell you whether that is native > or a configured tunnel? Not perfectly. But you can look at things like MSS and MTU. --000e0cd28fee8ab81d04a54c1e60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 9, 2011 at 12:01 PM, Brian E Carpent= er <bri= an.e.carpenter@gmail.com> wrote:
> In a similar way as Geoff measured 6to4 - looking at= SYNs. I suspect that
> the answer will be that much fewer users have configured tunnels than = 6to4,
> and that the failure rate is much lower.

Er, I'm currently on 2001:388:f000::xxxx
Do you have an algorithm that will tell you whether that is native
or a configured tunnel?

Not perfectly. But = you can look at things like MSS and MTU.=A0
--000e0cd28fee8ab81d04a54c1e60-- From tjc@ecs.soton.ac.uk Thu Jun 9 12:35:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F3511E80D8; Thu, 9 Jun 2011 12:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21ZwsFGSyIHL; Thu, 9 Jun 2011 12:35:12 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 06C3011E8089; Thu, 9 Jun 2011 12:35:07 -0700 (PDT) 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 p59JZ2Yv032395; Thu, 9 Jun 2011 20:35:02 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p59JZ2Yv032395 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1307648103; bh=q7D7VI6mRvCeXGgGN7BwWF8uSLo=; h=From:Mime-Version:Subject:Date:In-Reply-To:To:References; b=0GKdPR8HfOD/Ce7mLFjMNBqri5hpzqk3Bl9Lj/8KnsygDo648X1Cj1DY4jmUMWO5o 3FI6DXg6Wkh0pv99afwumcgV1rqDYjOzZRX3/j1n40u/e9jTaDAaem5P+eK0lp5YkG KXtSqC51GuYRDChkhwoG8vX6+o9XrP5/q8DAXABs= 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 n58KZ20035665161xU ret-id none; Thu, 09 Jun 2011 20:35:02 +0100 Received: from [192.168.1.14] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p59JYuVH015531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jun 2011 20:34:57 +0100 From: Tim Chown Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-775898431 Date: Thu, 9 Jun 2011 20:34:56 +0100 In-Reply-To: <0F2C8463-36AA-41D1-8D3F-735A623F484C@network-heretics.com> To: "v6ops@ietf.org WG" , ietf@ietf.org References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> <22F6318E46E26B498ABC828879B08D4F167D15@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <0F2C8463-36AA-41D1-8D3F-735A623F484C@network-heretics.com> Message-ID: X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n58KZ2003566516100; tid=n58KZ20035665161xU; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p59JZ2Yv032395 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 19:35:14 -0000 --Apple-Mail-1-775898431 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree the draft should be progressed, so add another +1 to the 'just = ship it' people. On 9 Jun 2011, at 18:39, Keith Moore wrote: > If pain associated with 6to4 provides an additional incentive for = ISPs to deploy native v6, and for users to use native v6 when it becomes = available, that's a Good Thing.=20 The pain though is felt by the content providers, who still see too much = brokenness. =20 On 9 Jun 2011, at 19:01, james woodyatt wrote: > I confidently predict the reclassification to Historic will be roundly = ignored not just by Apple product engineering but by the entire = industry. We're smart enough to recognize that we're not the target = audience for the RFC. The draft that matters is the companion advisory = draft. It would be nice if the 6to4-to-historic draft could be spiked = so as not to distract from its companion, but I don't see that as a = likely outcome. Alas and alack. Well, the most important point in this is that 6to4 is disabled by = default in every device. Apple did that already, which is good. What is = unclear to me though is whether deprecating 2002::/16 means that prefix = would no longer be routed, as per 3ffe::/16, or just 'reserved' so it's = not reallocated later. On 9 Jun 2011, at 19:53, Keith Moore wrote: > On Jun 9, 2011, at 2:45 PM, Lorenzo Colitti wrote: >> Go to http://tunnelbroker.net/ . I'm willing to bet that it will take = a lot less time than you have spent writing email on this thread. :-) >=20 > That's who I was using before. Our staff and students find the HE broker easy to use, though I believe = some also use other brokers. One student did a final year project this = year developing a Linux home router which included HE broker support. = It was simple to use/integrate. On 9 Jun 2011, at 19:56, james woodyatt wrote: > I need *native* IPv6 into my home in San Francisco for my day job Have you considered deploying/adding IPv6 VPN support at your day job? = So your VPN from home to work gives you IPv4 and IPv6? This is quite a = nice model, and is starting to appear in UK universities, and I use it = myself for IPv6 training. At least one big vendor offers this today. = Users are familiar with VPN use, so adding IPv6 with that comes = naturally, and $dayjob provides the support, so you're in control. > Meanwhile, 6to4 works fine on their network so long as remote IPv6 = destinations have a working return path route to 2002::/16, i.e. they = are complying with I-D.ietf-v6ops-6to4-advisory now. That 'so long as' is the crux though. Tim= --Apple-Mail-1-775898431 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = agree the draft should be progressed, so add another +1 to the 'just = ship it' people.

On 9 Jun 2011, at 18:39, Keith Moore = wrote:
 If pain associated = with 6to4 provides an additional incentive for ISPs to deploy native v6, = and for users to use native v6 when it becomes available, that's a Good = Thing. 

The pain though is = felt by the content providers, who still see too much brokenness. =  

On 9 Jun 2011, at 19:01, james woodyatt = wrote:
I confidently predict the = reclassification to Historic will be roundly ignored not just by Apple = product engineering but by the entire industry.  We're smart enough = to recognize that we're not the target audience for the RFC.  The = draft that matters is the companion advisory draft.  It would be = nice if the 6to4-to-historic draft could be spiked so as not to distract = from its companion, but I don't see that as a likely outcome.  Alas = and alack.

Well, the most important = point in this is that 6to4 is disabled by default in every device. =  Apple did that already, which is good. What is unclear to me = though is whether deprecating 2002::/16 means that prefix would no = longer be routed, as per 3ffe::/16, or just 'reserved' so it's not = reallocated later.

On 9 Jun 2011, at = 19:53, Keith Moore wrote:
On Jun 9, 2011, at = 2:45 PM, Lorenzo Colitti wrote:
Go to http://tunnelbroker.net/ . = I'm willing to bet that it will take a lot less time than you have spent = writing email on this thread. = :-)
That's who I was using = before.

Our staff and students = find the HE broker easy to use, though I believe some also use other = brokers.  One student did a final year project this year developing = a Linux home router which included HE broker support.  It was = simple to use/integrate.

On 9 Jun 2011, at = 19:56, james woodyatt wrote:
I need = *native* IPv6 into my home in San Francisco for my day = job

Have you considered = deploying/adding IPv6 VPN support at your day job?  So your VPN = from home to work gives you IPv4 and IPv6?  This is quite a nice = model, and is starting to appear in UK universities, and I use it myself = for IPv6 training. At least one big vendor offers this today. Users are = familiar with VPN use, so adding IPv6 with that comes naturally, and = $dayjob provides the support, so you're in = control.

Meanwhile, 6to4 works fine on their network so long = as remote IPv6 destinations have a working return path route to = 2002::/16, i.e. they are complying with I-D.ietf-v6ops-6to4-advisory = now.

That 'so long as' is the crux = though.

Tim
= --Apple-Mail-1-775898431-- From mrex@sap.com Thu Jun 9 14:31:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F55611E8142; Thu, 9 Jun 2011 14:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.337 X-Spam-Level: X-Spam-Status: No, score=-9.337 tagged_above=-999 required=5 tests=[AWL=0.913, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWP44Ytajygo; Thu, 9 Jun 2011 14:31:12 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E498B11E813A; Thu, 9 Jun 2011 14:31:11 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p59LV6T3023993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Jun 2011 23:31:06 +0200 (MEST) From: Martin Rex Message-Id: <201106092131.p59LV5cZ003693@fs4113.wdf.sap.corp> To: gert@space.net (Gert Doering) Date: Thu, 9 Jun 2011 23:31:05 +0200 (MEST) In-Reply-To: <20110609151640.GQ45955@Space.Net> from "Gert Doering" at Jun 9, 11 05:16:40 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ietf@ietf.org, moore@network-heretics.com, v6ops@ietf.org Subject: Re: [v6ops] Last Call: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 21:31:13 -0000 Gert Doering wrote: > > On Thu, Jun 09, 2011 at 11:05:29AM -0400, Keith Moore wrote: > > The best way to not rat-hole is just to drop the proposed action. > > One voice doesn't make it "consensus to drop". In the IETF, that is supposed to be possible. A single technical or procedural issue that is raised before or during Last Call and not resolved precludes IETF rough consensus. intention behind this include (using words from rfc2418): good working group consensus about a bad design. While the Tao (rfc-4677) is only informational, it seems to capture the IETF spirit quite good: "We reject kings, presidents and voting. We believe in rough consensus and running code". The lack of formal voting has caused some very long delays for some proposals, but most IETF participants who have witnessed rough consensus after acrimonious debates feel that the delays often result in better protocols. (And, if you think about it, how could you have "voting" in a group that anyone can join, and when it's impossible to count the participants?) Rough consensus has been defined in many ways; a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong. or look at rfc-4858, later parts of section 3.2, another Informational but valuable document. e.g. if an implementor raises an issue, one should carefully listen and talk about it, even if it is just one single implementor. The opposite, an implementor that does not see a problem is not proof of anything (as we can see from regular interop problems showing up only during interop tests). Reading specs correctly (and carefully) seems to be less common than is desirable. The purpose of the discussion is to seperate issues of taste (where significant majority decisions are OK) from technical&procedural issues and resolving all of the latter categorie(s) or determining technical issues to be out-of-scope. WG chairs and ADs have a significant discretion, and I've seen it happening that they got too personally involved, inducing a non-marginal bias on the issue resolution process in situations where this was unnecessary and not appropriate. That may or may not result in worse decision. But it is conceived as unfair by those holding the objections and a problem by itself because it regularly taints other discussions on other work items. -Martin From wesley.george@twcable.com Thu Jun 9 14:56:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DAE21F8465 for ; Thu, 9 Jun 2011 14:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.229 X-Spam-Level: X-Spam-Status: No, score=0.229 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hU4p0SEF1O2J for ; Thu, 9 Jun 2011 14:56:35 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFC321F8464 for ; Thu, 9 Jun 2011 14:56:32 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,343,1304308800"; d="scan'208";a="236483697" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 09 Jun 2011 18:03:58 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 9 Jun 2011 17:56:31 -0400 From: "George, Wesley" To: Joel Jaeggli , Fred Baker Date: Thu, 9 Jun 2011 17:56:30 -0400 Thread-Topic: [v6ops] Call for agenda items Thread-Index: AcwmIkteO9po9Ri8SVmOe/ohpUTOlwAzR31Q Message-ID: <34E4F50CAFA10349A41E0756550084FB0690A8EC@PRVPEXVS04.corp.twcable.com> References: <4DED7A3D.1060008@viagenie.ca> <8E93014B-E0BC-4001-95F4-D97917CFF2F6@cisco.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] Call for agenda items X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 21:56:35 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of J= oel Jaeggli Sent: Wednesday, June 08, 2011 5:34 AM To: Fred Baker Cc: v6ops@ietf.org Subject: Re: [v6ops] Call for agenda items Requesting more than 5 hours I think runs the risk of us overstating our va= lue to the organization. So we need to be judicious with our time and consider how and where reporti= ng on the event (or preparation for it) advances our charter goals and furt= hers work being done or under consideration. +1. It also makes it harder for folks to get to other WGs because the risk = of overlap increases significantly the more time any one group is using. Personally, I think that it would be better for a generic discussion around= World IPv6 day to be part of the Technical Plenary. It has applicability a= nd interest well beyond v6ops. What would be more useful is to perhaps reserve a couple of 10 minute times= lots for those who have identified a specific operational problem that they= discovered during World IPv6 Day that IETF and this WG should be addressin= g. Almost in the form of a NANOG lightning talk - problem statement, brief = explanation, why IETF can/should fix. Then they follow that up with a draft= that can be discussed in more detail on-list. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From fred@cisco.com Thu Jun 9 15:13:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F5011E80D5; Thu, 9 Jun 2011 15:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB+5MnydZKeD; Thu, 9 Jun 2011 15:13:51 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3F17311E80BB; Thu, 9 Jun 2011 15:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2364; q=dns/txt; s=iport; t=1307657630; x=1308867230; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=kZpLxLYwljocRS+/78xXlVVxa18Wnol2znWUikLlKoE=; b=hctPQTB9mTjOHxjt+/3tZ0N+jsAa9P4pWXkecHMXdjz/4pdp7UKbNJJn FijC3SjDEfGhiRRzgfxUIaYvZQ1CzBW5F4Z8AqSrdV/bo3aw8H4+ug0gd Zde85oBYWxtjEl7LTyImYb1QVJ8jFHk1zH3gJLzhHlxPVGfxPrNuOiYry U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFFF8U1Io8UR/2dsb2JhbABFDqZAd4hxoUCeCIMZgwoEhwiKIoRNiyU X-IronPort-AV: E=Sophos;i="4.65,343,1304294400"; d="scan'208";a="93219334" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2011 22:13:47 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p59MDbYE025263; Thu, 9 Jun 2011 22:13:43 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Thu, 09 Jun 2011 15:13:45 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Thu, 09 Jun 2011 15:13:45 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0690A8EC@PRVPEXVS04.corp.twcable.com> Date: Thu, 9 Jun 2011 15:13:21 -0700 Message-Id: <9101ECA5-40E4-48B0-90DE-ECA3E8C1E8D7@cisco.com> References: <4DED7A3D.1060008@viagenie.ca> <8E93014B-E0BC-4001-95F4-D97917CFF2F6@cisco.com> <34E4F50CAFA10349A41E0756550084FB0690A8EC@PRVPEXVS04.corp.twcable.com> To: "George, Wesley" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org Working Group" , IETF Chair , 6man-ads@tools.ietf.org, v6ops-ads@tools.ietf.org Subject: Re: [v6ops] Call for agenda items X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 22:13:52 -0000 On Jun 9, 2011, at 2:56 PM, George, Wesley wrote: > Personally, I think that it would be better for a generic discussion = around World IPv6 day to be part of the Technical Plenary. It has = applicability and interest well beyond v6ops. Copying the IETF chair and relevant ADs. We need to identify an = appropriate speaker, but I think this is a good idea. I could imagine = Leslie Daigle, Bob Hinden, or one of a list of luminaries from various = operators and enterprises. In fact, I could imagine it being a panel = with three or four people coming at it from different perspectives. > What would be more useful is to perhaps reserve a couple of 10 minute = timeslots for those who have identified a specific operational problem = that they discovered during World IPv6 Day that IETF and this WG should = be addressing. Almost in the form of a NANOG lightning talk - problem = statement, brief explanation, why IETF can/should fix. Then they follow = that up with a draft that can be discussed in more detail on-list. Speaking for myself, I have a problem with folks speaking with a promise = of a follow-up internet draft; I don't think I have ever seen the = promised draft. Because of that, I tend to be very firm on the notion = that the draft opens the option of giving a talk. Willing to be told I'm = wrong, of course. But let me turn that around in a different way. Let's use this list as a = "lightning round" for the coming two weeks. I'll invite emails of your = proposed form - problem statement, brief explanation, why IETF = can/should fix, and if obvious, a brief sketch of a possible fix. I'm = obviously not looking for tomes, and not looking for statements of the = form "my idiot competitor/vendor/customer X..." - those are discussions = to have with the relevant idiot. I suspect that if we spend the next 1-2 weeks in a lightning round on = the list, we will have coalitions interested in specific problems and = solutions form, which will be in a position to file a -00 draft by 4 = July. Charter guideline - if you're describing a protocol or a change to = a protocol, that will wind up in 6man, behave, softwire, or some other = appropriate working group. v6ops is for purely operational discussions. Those, in turn, may be very useful outputs from the test and inputs to = the IETF.= From newbery@gmail.com Thu Jun 9 19:01:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE5311E80E3 for ; Thu, 9 Jun 2011 19:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tC5tW3Duph6o for ; Thu, 9 Jun 2011 19:01:39 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB6711E8080 for ; Thu, 9 Jun 2011 19:01:39 -0700 (PDT) Received: by pxi20 with SMTP id 20so1624421pxi.27 for ; Thu, 09 Jun 2011 19:01:39 -0700 (PDT) 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=XaiNZaR4KUS/mJOlvuF6pcrygS3fcDh9sEMpAl3YuCA=; b=PMIikVnMokhyvurvyjn1UnV+I/w2I7+5rHa5XU4LWFV8KeNIvK5kf7lfRo2Q5JuAUj mawH19Cfwju09Kj9J32+axdpMm/TY9wz8y541kpleFkQ/tWvlOdDq7LXHvsoMWUlGD7n z9k4oN9XlNYZB/L8a65VYCyHA3fnNQonfLcpM= 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=XJ2KpkFfsT0KnZgwIXYZSU6xqX2NS22TebCSaSjim4tKVCtD+E8CwUAykr3C7bdp4l SMTPgIpRUumShu9Rl2ijWqIRgdjwiaGi7/AYdpTsatk5V5M/TgWbCzIG+BsgoWGYehje SLCebtsfo75nuIXRm+907DvdWnAecmBXYMB+A= Received: by 10.68.32.234 with SMTP id m10mr712468pbi.13.1307671298937; Thu, 09 Jun 2011 19:01:38 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id p5sm1885073pbk.68.2011.06.09.19.01.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2011 19:01:37 -0700 (PDT) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-7-799094872; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 10 Jun 2011 14:01:28 +1200 In-Reply-To: <056CE2B5-5DE5-4B0D-B38B-569C011B2733@apple.com> To: "v6ops@ietf.org WG" References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <677F8425-F710-403E-B59B-F3CCEBF711C7@apple.com> <056CE2B5-5DE5-4B0D-B38B-569C011B2733@apple.com> Message-Id: <2F3F96CA-9407-41BA-8580-6D4315B655F7@gmail.com> X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 02:01:40 -0000 --Apple-Mail-7-799094872 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 10/06/2011, at 6:01 AM, james woodyatt wrote: >=20 > I don't see why this draft should discourage anyone from continuing to = support 6to4, which as you point out is a *uniquely* useful protocol = that people depend on and find *irreplaceable*. Reclassifying it as = Historic simply allows IETF working groups to operate on the fiction = that 6to4 will eventually disappear someday in the indefinite and = vaguely hopeful future. While I don't think that self-delusion will be = a good thing for IETF in the long run, I have a hard time getting too = bummed out about it. Pragmatism will find its way into deliberations. >=20 > Yes, I think this draft is a pointless waste of time. The reason I = support publishing it, however, is that I disagree with your assessment = of the harm it could do. Also, it enjoys widespread support in the = V6OPS working group and the opposition, while vocal, seems quite small. = That looks like rough consensus to me, and if I can help get it off our = agenda sooner by supporting it rather than opposing it, then I say let's = print it. >=20 > I confidently predict the reclassification to Historic will be roundly = ignored not just by Apple product engineering but by the entire = industry. We're smart enough to recognize that we're not the target = audience for the RFC. The draft that matters is the companion advisory = draft. It would be nice if the 6to4-to-historic draft could be spiked = so as not to distract from its companion, but I don't see that as a = likely outcome. Alas and alack. I agree with James on this. 6to4 is better than nothing. This RFC won't make existing 6to4 go away. = Those of us who want to support our users may continue to support 6to4 = relays until we can get native v6 working---at which point said relays = can die as far as I'm concerned. There is little point in making a better 6to4 protocol. Better to put = that effort into deploying native v6. (There _is_ some point in stopping = protocol 41 brokenness, which helps 6to4---but also helps other things = too.) If we want to identify a great evil whose time is passed and which = should die, die, die! then I quixotically suggest LSN. But again, rather = than waste time on that, can't we just move on and invest in native = IPv6? +1 to the draft= --Apple-Mail-7-799094872 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 AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwNjEwMDIwMTMz WjAjBgkqhkiG9w0BCQQxFgQUH1/su8RmqJf9721SN1FohI8qZiswgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCbnFMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCbnFMA0GCSqG SIb3DQEBAQUABIIBABvsZSTylo4BrMagLriO3FL9PYVb4WEKoRGwtuyncERfqxNWW7VRNXx8bqLb P/gkVLIka3fZSPorvETQzYw6Cswv/sn4HhPdhFujvDxdzZEqMjV3Q2SRU1ZM+VI7ycPn5dO26MxO HXBVoNTupi1cvMM0fnLeHqvCHTRfDf277OlhbTH3i7PFHsbLqjeb8oEFY9ktzgpKgrDNDhxeeHhm oGnr89TalB7kGl/vThLjCXaPC8F8dOJvnZFRNlJOoKRXNegAMZzbixNiaWp1lMqjzq7QYwUc/ZN7 G7g4BNV+pIsN0m/eIDiFsDDgxo45wChwNIDCM8b4yKlCheTTjBg6pIoAAAAAAAA= --Apple-Mail-7-799094872-- From jari.arkko@piuha.net Thu Jun 9 21:26:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2118311E8146; Thu, 9 Jun 2011 21:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.146 X-Spam-Level: X-Spam-Status: No, score=-102.146 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbSDTsEOlZkP; Thu, 9 Jun 2011 21:26:33 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 55A9511E8078; Thu, 9 Jun 2011 21:26:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3E6842CC3C; Fri, 10 Jun 2011 07:26:26 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VwW5hVIRgbZ; Fri, 10 Jun 2011 07:26:25 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 0B5702CC3B; Fri, 10 Jun 2011 07:26:25 +0300 (EEST) Message-ID: <4DF19CF0.4070508@piuha.net> Date: Fri, 10 Jun 2011 07:26:24 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "George, Wesley" , Fred Baker References: <4DED7A3D.1060008@viagenie.ca> <8E93014B-E0BC-4001-95F4-D97917CFF2F6@cisco.com> <34E4F50CAFA10349A41E0756550084FB0690A8EC@PRVPEXVS04.corp.twcable.com> In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0690A8EC@PRVPEXVS04.corp.twcable.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , IETF Chair , 6man-ads@tools.ietf.org Subject: Re: [v6ops] Call for agenda items X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 04:26:34 -0000 I think the World IPv6 Day results are a very interesting topic, deserving of highest level of attention from the IETF and operational conferences. That being said, the technical plenary is run by the IAB and they often plan well in advance. They might have another topic already. But I think we should discuss the results at least in V6OPS and if needed also in 6MAN and INTAREA. In any case, when we discuss the World IPv6 Day I think the focus should be on understanding what happened. NOT on sketching solutions or even focusing on problem statements or asking specific IETF working groups to take on work. Many people who were running the networks that day commented as the day being boring -- and that's a good thing as no surprising problems or major catastrophes developed. But of course the devil is in the details and we have to analyze the data. From my perspective it would be interesting to focus on the following: o Many large organizations updated their network successfully to IPv6. What did we learn from those efforts? o Measurements, analysis and anecdotes about traffic and networking issues during the day. What worked, where are the problems if there are any? o Implications of the experiences. What are the implications for our 6to4 discussion? Whitelisting? Happy eyeballs? Continued stream of incoming transition tool proposals for the IETF? Can we quantify various problems that we've discussed better after the day? Which problems are non-problems and which ones are real? The day was not special just in that many organizations provided IPv6 service. It was also special in that there were many, many groups taking measurements. We need to dig into that pool of data. Jari From tena@huawei.com Thu Jun 9 21:44:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB6011E80BB; Thu, 9 Jun 2011 21:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LEzylWii40Q; Thu, 9 Jun 2011 21:44:31 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1533211E8078; Thu, 9 Jun 2011 21:44:31 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMK00HCJ5648Y@usaga02-in.huawei.com>; Thu, 09 Jun 2011 23:44:29 -0500 (CDT) Received: from TingZousc1 ([10.193.34.221]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMK00168563LH@usaga02-in.huawei.com>; Thu, 09 Jun 2011 23:44:28 -0500 (CDT) Date: Thu, 09 Jun 2011 21:44:29 -0700 From: Tina Tsou In-reply-to: <4DF19CF0.4070508@piuha.net> To: 'Jari Arkko' , "'George, Wesley'" , 'Fred Baker' Message-id: <02a201cc2729$16427be0$42c773a0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwnJstNPuG0A7U5Ql6NA9IecCkLGgAAa2ng References: <4DED7A3D.1060008@viagenie.ca> <8E93014B-E0BC-4001-95F4-D97917CFF2F6@cisco.com> <34E4F50CAFA10349A41E0756550084FB0690A8EC@PRVPEXVS04.corp.twcable.com> <4DF19CF0.4070508@piuha.net> Cc: v6ops@ietf.org, 'IETF Chair' , 6man-ads@tools.ietf.org Subject: Re: [v6ops] Call for agenda items X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 04:44:32 -0000 Jari, >From my experience working out the dual stack www.huawei.com for World IPv6 Day in the past 3 months, the dual stack and old fashion tunneling are most useful tool kits. When we conclude the World IPv6 Day test, we are proud that we didn't sacrifice v4 end user performance at all while delivering a v6-enabled site. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Thursday, June 09, 2011 9:26 PM To: George, Wesley; Fred Baker Cc: v6ops@ietf.org; IETF Chair; 6man-ads@tools.ietf.org Subject: Re: [v6ops] Call for agenda items I think the World IPv6 Day results are a very interesting topic, deserving of highest level of attention from the IETF and operational conferences. That being said, the technical plenary is run by the IAB and they often plan well in advance. They might have another topic already. But I think we should discuss the results at least in V6OPS and if needed also in 6MAN and INTAREA. In any case, when we discuss the World IPv6 Day I think the focus should be on understanding what happened. NOT on sketching solutions or even focusing on problem statements or asking specific IETF working groups to take on work. Many people who were running the networks that day commented as the day being boring -- and that's a good thing as no surprising problems or major catastrophes developed. But of course the devil is in the details and we have to analyze the data. From my perspective it would be interesting to focus on the following: o Many large organizations updated their network successfully to IPv6. What did we learn from those efforts? o Measurements, analysis and anecdotes about traffic and networking issues during the day. What worked, where are the problems if there are any? o Implications of the experiences. What are the implications for our 6to4 discussion? Whitelisting? Happy eyeballs? Continued stream of incoming transition tool proposals for the IETF? Can we quantify various problems that we've discussed better after the day? Which problems are non-problems and which ones are real? The day was not special just in that many organizations provided IPv6 service. It was also special in that there were many, many groups taking measurements. We need to dig into that pool of data. Jari _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Fri Jun 10 06:55:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4478D11E817F for ; Fri, 10 Jun 2011 06:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4p+lToGVFzhT for ; Fri, 10 Jun 2011 06:55:01 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id AFD4F11E8135 for ; Fri, 10 Jun 2011 06:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=129; q=dns/txt; s=iport; t=1307714101; x=1308923701; h=date:from:message-id:to:subject:cc; bh=vo5KscV/ggO9cDl/iEfuls03fTV5QdkYa0/bk0SOlEg=; b=m1iuEUhM1u2BXi+nsc0QsiHziInMBTWlg58+6UsPRowlxWkhZZ3lA6Hn U0wyLzZab3MzS7al/o/qmu/cIKDNIl/1m8worVBwJYqqCBrXtCNYMX1dt xX1WeH9IY9S8rqW5HWtXwesDjxfdKifOYcOr8t3uHXYix1cP/nLUKeQIu A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEHACkh8k2rRDoI/2dsb2JhbABSmBABAY4zd6dpng+GIwSHCJoa X-IronPort-AV: E=Sophos;i="4.65,347,1304294400"; d="scan'208";a="334368737" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 10 Jun 2011 13:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5ADt1Yr020237; Fri, 10 Jun 2011 13:55:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p5ADt1t06787; Fri, 10 Jun 2011 06:55:01 -0700 (PDT) Date: Fri, 10 Jun 2011 06:55:01 -0700 (PDT) From: Message-Id: <201106101355.p5ADt1t06787@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-yang-v6ops-space6-icp@tools.ietf.org Subject: [v6ops] new draft: draft-yang-v6ops-space6-icp-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:55:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-yang-v6ops-space6-icp. Please take a look at it and comment. From jnc@mercury.lcs.mit.edu Fri Jun 10 09:18:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AFA1F0C88; Fri, 10 Jun 2011 09:18:17 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzldUS8B1Fqy; Fri, 10 Jun 2011 09:18:16 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 70B281F0C89; Fri, 10 Jun 2011 09:18:07 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 99D1618C0F6; Fri, 10 Jun 2011 12:18:06 -0400 (EDT) To: ietf@ietf.org, v6ops@ietf.org Message-Id: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> Date: Fri, 10 Jun 2011 12:18:06 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 16:18:18 -0000 > From: Lorenzo Colitti > Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure > rate when connecting to dual-stack servers than Mac OS 10.6.5 - and the > only change is to not use 6to4 by default. > ... > So the existence of 6to4 is in itself a significant barrier for IPv6 > deployment Surely you meant to say "the _incorrect configuration_ of 6to4 is in itself a significant barrier"? I get the impression that the problem comes in when 6to4 is configured on by default, and too high in the priority list (as opposed to native, other methods, etc). So fix the real issue, don't try and prematurely kill off something that's being used by lots of people. Noel From lorenzo@google.com Fri Jun 10 09:38:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762F81F0C8D for ; Fri, 10 Jun 2011 09:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkdjVdcD0sPg for ; Fri, 10 Jun 2011 09:38:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id F15761F0C43 for ; Fri, 10 Jun 2011 09:38:56 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p5AGctOq010739 for ; Fri, 10 Jun 2011 09:38:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307723935; bh=9Ij3LdwmjeEYygvBJvV1IL1JGuY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=oIVpZTJYAtG0lbOm1eR+6zjn7jU0wJ20u7GxPaC8JpT71+njn5mPHmjLAR6I8ACsr eV2TQdzyjCdtr9idj3hcg== Received: from gxk21 (gxk21.prod.google.com [10.202.11.21]) by hpaq11.eem.corp.google.com with ESMTP id p5AGbmvQ016289 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 10 Jun 2011 09:38:54 -0700 Received: by gxk21 with SMTP id 21so2462366gxk.5 for ; Fri, 10 Jun 2011 09:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MgIqOIu5n2dTSwSoiBeN7HyhMQSU2VT9amCF9fDDQW4=; b=J6UaXE/esR4IKCDt0ZbLdELXqMjVv5Dx3IW4kHlN0X+XnvnW4Xotx3EJLgFT4pZVnd T36N6wFi5dotbi3jK3ig== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=YtzLWG5WpAjDl7Fih6lFmcoJoJLCzJcXA6H9tCzSRYIriOxxbso+xkopAEpEYn22Zg QE6104+RKyBFNtsMmfgA== Received: by 10.150.116.1 with SMTP id o1mr3246545ybc.321.1307723934101; Fri, 10 Jun 2011 09:38:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.95.20 with HTTP; Fri, 10 Jun 2011 09:38:34 -0700 (PDT) In-Reply-To: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> From: Lorenzo Colitti Date: Fri, 10 Jun 2011 09:38:34 -0700 Message-ID: To: Noel Chiappa Content-Type: multipart/alternative; boundary=000e0cd3b0408e72ca04a55e342e X-System-Of-Record: true Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 16:38:57 -0000 --000e0cd3b0408e72ca04a55e342e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 10, 2011 at 9:18 AM, Noel Chiappa wrote: > > Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure > > rate when connecting to dual-stack servers than Mac OS 10.6.5 - and > the > > only change is to not use 6to4 by default. > > ... > > So the existence of 6to4 is in itself a significant barrier for IPv6 > > deployment > > Surely you meant to say "the _incorrect configuration_ of 6to4 is in itself > a > significant barrier"? > You cannot expect something to be configured correctly if it is simply turned on without a) being managed by someone or b) detection mechanisms to see if it's working. Sadly, anycasted 6to4 meets neither of these conditions. > I get the impression that the problem comes in when 6to4 is configured on > by default, and too high in the priority list (as opposed to native, other > methods, etc). So fix the real issue, don't try and prematurely kill off > something that's being used by lots of people. I fundamentally disagree. I really don't think that 6to4 is used by "lots" of people for applications that wouldn't just use (more reliable) IPv4 if 6to4 wasn't there. --000e0cd3b0408e72ca04a55e342e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 10, 2011 at 9:18 AM, Noel Chiappa <jnc@mercury.= lcs.mit.edu> wrote:
=A0 =A0> Mac OS 10.6.4, which uses 6to4 by default, ha= s a ~50x greater failure
=A0 =A0> rate when connecting to dual-stack servers than Mac OS 10.6.5 = - and the
=A0 =A0> only change is to not use 6to4 by default.
=A0 =A0> ...
=A0 =A0> So the existence of 6to4 is in itself a sign= ificant barrier for IPv6
=A0 =A0> deployment

Surely you meant to say "the _incorrect configuration_ of 6to4 i= s in itself a
significant barrier"?

You cannot e= xpect something to be configured correctly if it is simply turned on withou= t a) being managed by someone or b) detection mechanisms to see if it's= working. Sadly, anycasted 6to4 meets neither of these conditions.
=A0
I get the impression that the= problem comes in when 6to4 is configured on by=A0default, and too high in = the priority list (as opposed to native, other
methods, etc). So fix the real issue, don't try and prematurely kill of= f
something that's being used by lots of people.

I fundamentally disagree. I really don't think that 6to4 is use= d by "lots" of people for applications that wouldn't just use= (more reliable) IPv4 if 6to4 wasn't there.
--000e0cd3b0408e72ca04a55e342e-- From jhw@apple.com Fri Jun 10 10:15:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD1611E8090; Fri, 10 Jun 2011 10:15:21 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNsHeZNxDi9D; Fri, 10 Jun 2011 10:15:20 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 571A811E8077; Fri, 10 Jun 2011 10:15:20 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LML004753J5DN80@mail-out.apple.com>; Fri, 10 Jun 2011 10:15:19 -0700 (PDT) X-AuditID: 11807130-b7c15ae000005aca-28-4df251260234 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 12.2C.23242.72152FD4; Fri, 10 Jun 2011 10:15:19 -0700 (PDT) Received: from 67-218-102-220.cust.layer42.net (67-218-102-220.cust.layer42.net [67.218.102.220]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LML008VE3XIEA00@koseret.apple.com>; Fri, 10 Jun 2011 10:15:18 -0700 (PDT) From: james woodyatt In-reply-to: Date: Fri, 10 Jun 2011 10:15:19 -0700 Message-id: <3B25F81A-89D1-4272-942C-A699C8593099@apple.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> To: IETF Discussion X-Mailer: Apple Mail (2.1237.1) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Operations Working Group Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 17:15:21 -0000 On Jun 9, 2011, at 10:42 AM, Lorenzo Colitti wrote: > > We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by default... I don't want anybody to be misled by this statement. I think what Lorenzo meant to say is that Mac OS X 10.6.4 and earlier doesn't implement the policy table in I-D.ietf-6man-rfc3484-revise, which prefers IPv4 source addresses over 2002::/16 IPv6 source addresses. Mac OS X has *never* used 6to4 by default. The scenario Lorenzo is talking about is where a router is advertising a 6to4 prefix onto a native IPv6 link. On those links, Mac OS X 10.6.4 and earlier will treat 6to4 prefixes equivalently to any other IPv6 prefix when making address selection decisions. -- james woodyatt member of technical staff, core os networking From lorenzo@google.com Fri Jun 10 10:23:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4086121F84A6 for ; Fri, 10 Jun 2011 10:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T8PCWw6jFHd for ; Fri, 10 Jun 2011 10:23:02 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id A312C21F849C for ; Fri, 10 Jun 2011 10:23:01 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p5AHN05k027164 for ; Fri, 10 Jun 2011 10:23:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307726580; bh=cvFg8G7R+wtyVWdM2wX1DNWh9Cw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=vltoIYTYVhlYjWJCwKghRRdlGA6WhppInXTqOlWmP0XyKTvgSWOL3H7TZ5UbspWqv mBpBn9JqrpWIKBdacv+hA== Received: from yxl31 (yxl31.prod.google.com [10.190.3.223]) by wpaz24.hot.corp.google.com with ESMTP id p5AHJdgb021359 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 10 Jun 2011 10:22:59 -0700 Received: by yxl31 with SMTP id 31so918554yxl.38 for ; Fri, 10 Jun 2011 10:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qqZpfp0p8B8xGmC3V9pYh1GgjqUO2G8Fa9nnbXNlZzs=; b=UWSPVqSsnGpKho5VBEQf1aCIUj6hQ+anmcb6+XbcxrjBeouD4YWLQAQtYNm+r5AeLC GhWv2RygdLckZ95cHJ3Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=qjgGwGukGJPrMgKkpgoms+4NwDwb0fkke0Cd8WuHqwVtHNoDdv+NmS256HKx5Q2HBE tiK8Bk1xp3kZ4okYpuMA== Received: by 10.150.183.3 with SMTP id g3mr3315912ybf.264.1307726579096; Fri, 10 Jun 2011 10:22:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.95.20 with HTTP; Fri, 10 Jun 2011 10:22:39 -0700 (PDT) In-Reply-To: <3B25F81A-89D1-4272-942C-A699C8593099@apple.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <3B25F81A-89D1-4272-942C-A699C8593099@apple.com> From: Lorenzo Colitti Date: Fri, 10 Jun 2011 10:22:39 -0700 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=000e0cd6ecd835de9404a55ed291 X-System-Of-Record: true Cc: IPv6 Operations Working Group , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 17:23:03 -0000 --000e0cd6ecd835de9404a55ed291 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 10, 2011 at 10:15 AM, james woodyatt wrote: > I don't want anybody to be misled by this statement. I think what Lorenzo > meant to say is that Mac OS X 10.6.4 and earlier doesn't implement the > policy table in I-D.ietf-6man-rfc3484-revise, which prefers IPv4 source > addresses over 2002::/16 IPv6 source addresses. > Yes, of course. I was trying to keep it short. --000e0cd6ecd835de9404a55ed291 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 10, 2011 at 10:15 AM, james woodyatt= <jhw@apple.com&g= t; wrote:
I don't want anybody to be misled by this statement. =A0I think what Lo= renzo meant to say is that Mac OS X 10.6.4 and earlier doesn't implemen= t the policy table in I-D.ietf-6man-rfc3484-revise, which prefers IPv4 sour= ce addresses over 2002::/16 IPv6 source addresses.

Yes, of course. I was trying to keep it sh= ort.=A0
--000e0cd6ecd835de9404a55ed291-- From joelja@bogus.com Fri Jun 10 10:57:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DBC11E81D1; Fri, 10 Jun 2011 10:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4N3Dw0HvDIUC; Fri, 10 Jun 2011 10:57:00 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C8DA711E81A0; Fri, 10 Jun 2011 10:56:59 -0700 (PDT) Received: from 000154tjennings.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p5AHutTS018327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 10 Jun 2011 17:56:57 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-856412113 From: Joel Jaeggli In-Reply-To: <12313.1307727837@marajade.sandelman.ca> Date: Fri, 10 Jun 2011 10:56:50 -0700 Message-Id: <950C6940-C1C2-4AA5-AB32-621B3150682D@bogus.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> <12313.1307727837@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 10 Jun 2011 17:56:58 +0000 (UTC) Cc: "v6ops@ietf.org" , "ietf@ietf.org" Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 17:57:00 -0000 --Apple-Mail-1-856412113 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 10, 2011, at 10:43 AM, Michael Richardson wrote: >=20 > This all reminds of how killing the mbone killed multicast. Getting grumpy email from van because I sourced more than 128Kb/s killed = the mbone, it was a toy.=20 joel= --Apple-Mail-1-856412113 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jun 10, 2011, at 10:43 AM, Michael Richardson wrote:

This all reminds of how killing the mbone killed multicast.

Getting grumpy email from van because I sourced more than 128Kb/s killed the mbone, it was a toy. 

joel
--Apple-Mail-1-856412113-- From Fred.L.Templin@boeing.com Fri Jun 10 11:15:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5688E9E800B; Fri, 10 Jun 2011 11:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqd-9vw1qD8h; Fri, 10 Jun 2011 11:15:47 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id B56969E8004; Fri, 10 Jun 2011 11:15:47 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5AIFeXS013921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Jun 2011 11:15:41 -0700 (PDT) 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 p5AIFe3N023116; Fri, 10 Jun 2011 11:15:40 -0700 (PDT) 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 p5AIFelN023098 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 10 Jun 2011 11:15:40 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Fri, 10 Jun 2011 11:15:40 -0700 From: "Templin, Fred L" To: Lorenzo Colitti , Noel Chiappa Date: Fri, 10 Jun 2011 11:15:39 -0700 Thread-Topic: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC Thread-Index: AcwnjPOsyFstRw0iRie7BDfF+VdQ/gADQvSA Message-ID: References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A65C6A7E6A9AXCHNW01Vnwnos_" MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 18:15:48 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A65C6A7E6A9AXCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You cannot expect something to be configured correctly if it is simply turn= ed on without a) being managed by someone or b) detection mechanisms to see= if it's working. Sadly, anycasted 6to4 meets neither of these conditions. ISATAP meets both of these conditions: http://tools.ietf.org/html/draft-templin-v6ops-isops Fred --_000_E1829B60731D1740BB7A0626B4FAF0A65C6A7E6A9AXCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
You cannot expect something to be configured correctly if it is simp= ly=20 turned on without a) being managed by someone or b) detection mechanisms = to=20 see if it's working. Sadly, anycasted 6to4 meets neither of these=20 conditions.  
ISATAP meets=20 both of these conditions:
 
http://tools.= ietf.org/html/draft-templin-v6ops-isops
 
Fred
 
 
--_000_E1829B60731D1740BB7A0626B4FAF0A65C6A7E6A9AXCHNW01Vnwnos_-- From moore@network-heretics.com Fri Jun 10 11:29:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C2811E8119; Fri, 10 Jun 2011 11:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b4SpRxxY8-C; Fri, 10 Jun 2011 11:29:00 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id B718111E80FF; Fri, 10 Jun 2011 11:29:00 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 61FDB20D87; Fri, 10 Jun 2011 14:29:00 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 10 Jun 2011 14:29:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=DPjzCqFhLzX5/QmpXY9vhLngf5w=; b=bM+xYZksZ0iVbGVB6J4jwHmmzyaTlHNJM5iHkyOH6T+vFXgQWFz0CdL/bstNjCJwy9ho+CcpHcy/OOBqdZF890u0uODpHYjNaeLp7kbVNPJLPL8NSA1ye3ksj2PyfypJeH9Sg9vSvEa7Lri2HduximfRLY/gdSJTmhUqOMJugFU= X-Sasl-enc: SR7dJPTU35esJmbJBBZq3w4FpJZreaaESap45owLQIlu 1307730539 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 579E840727F; Fri, 10 Jun 2011 14:28:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <3B25F81A-89D1-4272-942C-A699C8593099@apple.com> Date: Fri, 10 Jun 2011 14:28:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8C6D95F6-49D3-49CD-A737-D24138DC631F@network-heretics.com> References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <3B25F81A-89D1-4272-942C-A699C8593099@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Working Group , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 18:29:01 -0000 On Jun 10, 2011, at 1:15 PM, james woodyatt wrote: > On Jun 9, 2011, at 10:42 AM, Lorenzo Colitti wrote: >>=20 >> We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 = by default... >=20 > I don't want anybody to be misled by this statement. I think what = Lorenzo meant to say is that Mac OS X 10.6.4 and earlier doesn't = implement the policy table in I-D.ietf-6man-rfc3484-revise, which = prefers IPv4 source addresses over 2002::/16 IPv6 source addresses. >=20 > Mac OS X has *never* used 6to4 by default. The scenario Lorenzo is = talking about is where a router is advertising a 6to4 prefix onto a = native IPv6 link. On those links, Mac OS X 10.6.4 and earlier will = treat 6to4 prefixes equivalently to any other IPv6 prefix when making = address selection decisions. thanks for clearing that up. I was pretty sure it wasn't true, but you = saved me the trouble of reinstalling 10.6.4 to prove it. Keith From fernando.gont.netbook.win@gmail.com Fri Jun 10 15:08:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0678711E81D4; Fri, 10 Jun 2011 15:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.778 X-Spam-Level: X-Spam-Status: No, score=-2.778 tagged_above=-999 required=5 tests=[AWL=0.822, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBDMongDPP5D; Fri, 10 Jun 2011 15:08:27 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 36C5411E8104; Fri, 10 Jun 2011 15:08:27 -0700 (PDT) Received: by ywp31 with SMTP id 31so1575568ywp.31 for ; Fri, 10 Jun 2011 15:08:26 -0700 (PDT) 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:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=LJCWCqhfSC5IVj+XF4amDXXNRadXPhy6uZBxNmXWyMg=; b=xiYuAAAVVC6C10wdipLGs2PCgK3CiLo2CUXAl0ufAxQehXbk9zsq9Kj/xbJBrh35yV JT/hTeZlW7TH9JDllLIlA9+hJE9tR/QAMLtcEOMvyrL4e9cE0y3ji0dHqf8hOknokFCp O0kMqQvTFZ7h8l+2Iy4xChMd3vQt58F9RfkKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=OgV8nakN1z7z7KCF4P/eNz6MetGamVjm4OdWItWgKxc1bRezqoZGb5+IKajn8LXSjI MbLZKuJewajClfgn17ZuDjeN0yoUQfF4nC90FtWzjrO1exCNJ6HbeAttDZCkMJ8k/yA2 gwVrZgStSCt6jwYwpEN94zdh7F0IlblpDdQUc= Received: by 10.91.173.11 with SMTP id a11mr3623443agp.105.1307743706675; Fri, 10 Jun 2011 15:08:26 -0700 (PDT) Received: from [192.168.123.103] ([190.48.244.18]) by mx.google.com with ESMTPS id x33sm2946286ana.22.2011.06.10.15.08.24 (version=SSLv3 cipher=OTHER); Fri, 10 Jun 2011 15:08:26 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DF291D0.7080707@gont.com.ar> Date: Fri, 10 Jun 2011 18:51:12 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: IPv6 Operations , "ipv6@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 22:08:28 -0000 Hi, Some folks have expressed (both on-list and off-list) that they would prefer a less agressive solution for the RA-Guard evasion vulnerability. So I'd like to hear comments about the possible alternatives.. The current I-Ds (draft-gont-6man-nd-extension-headers and draft-gont-v6ops-ra-guard-evasion) basically take this approach: * Prohibit use of extension headers in ND messages. A host implementation must not produce these packets, and must discard them if it receives them * This results in a RA-Guard implementation that is as simple as possible (it only has to look at the header following the fixed IPv6 header). A more relaxed approach would be as follows: * Extension headers are allowed with ND messages. * If the packet is fragmented, the upper-layer header (ICMPv6 in this case) must be present in the first fragment (i.e., hosts must not generate packets that violate this requirement, and must discard them if they receive them). * Possibly have the RA-Guard box enforce a limit on the maximum number of extension headers that it will process (e.g., if after jumping to the, say 10th header the upper-layer header is not found, drop the packet) * This approach is less aggressive than the one proposed in the aforementioned I-Ds (i.e., more flexibility), but of course would also mean that the RA-Guard implementation would need to follow the header chain, thus leading to increased complexity, and possible performance issues. Any comments/thoughts will be very much appreciated. 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 mcr@sandelman.ca Fri Jun 10 10:42:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0431C11E816F; Fri, 10 Jun 2011 10:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 045LQpIQsAp9; Fri, 10 Jun 2011 10:42:15 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 423B211E80B7; Fri, 10 Jun 2011 10:42:15 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 0D64A3414F; Fri, 10 Jun 2011 13:42:15 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 535AC98A11; Fri, 10 Jun 2011 13:43:57 -0400 (EDT) From: Michael Richardson To: "v6ops@ietf.org" , "ietf@ietf.org" In-Reply-To: References: <20110606162326.26262.53944.idtracker@ietfa.amsl.com> <34E4F50CAFA10349A41E0756550084FB067B7388@PRVPEXVS04.corp.twcable.com> <08CD7CDC-E67F-4A59-9035-6D4C8C92BAB6@network-heretics.com> <34E4F50CAFA10349A41E0756550084FB067B7752@PRVPEXVS04.corp.twcable.com> <840209E6-606E-4823-8E6B-43D7C8EDE84D@network-heretics.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Fri, 10 Jun 2011 13:43:57 -0400 Message-ID: <12313.1307727837@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Fri, 10 Jun 2011 15:21:52 -0700 Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 17:42:16 -0000 >>>>> "Lorenzo" == Lorenzo Colitti writes: >> Why are you trying to make life harder for developers of IPv6 >> applications? There's no reason at all that an application >> developer should have to set up a special-purpose network just to >> test an IPv6 application. >> Lorenzo> No, we're trying to make their lives easier, by suggesting Lorenzo> they use something that actually *works*. >> Realistic testing of applications needs to be done on real >> networks, or a least an approximation to real networks. Testing >> IPv6 using 6to4 over public IPv4 obviously isn't perfect, but >> it's a hell of a lot more realistic than setting up a lab network >> and confining one's testing to that. Lorenzo> So use a tunnel broker. My tunnel broker has a machine with broken IPv4 routing, which they can't fix. It's been down for a week+ now. We had to renumber that location in time for World IPv6 day. We only had 6 machines that were using their non-autoconfigured addresses, so the rest was just a s///g in the DNS zone file. 6to4 would have turned this into my problem (which I could have fixed), but since some places like google refuse to run their own 6to4 relay, I can't really use 6to4 to talk to. Thanks. This all reminds of how killing the mbone killed multicast. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From ipng@69706e6720323030352d30312d31340a.nosense.org Fri Jun 10 18:15:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB98F11E809A; Fri, 10 Jun 2011 18:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7CoqFyfD9aJ; Fri, 10 Jun 2011 18:15:53 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id B98E39E8027; Fri, 10 Jun 2011 18:15:52 -0700 (PDT) Received: from 219-90-139-83.ip.adam.com.au ([219.90.139.83] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QVCne-0003VG-05; Sat, 11 Jun 2011 10:45:42 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 9213F3B338; Sat, 11 Jun 2011 10:45:40 +0930 (CST) Date: Sat, 11 Jun 2011 10:45:37 +0930 From: Mark Smith To: Fernando Gont Message-ID: <20110611104537.40918bcd@opy.nosense.org> In-Reply-To: <4DF291D0.7080707@gont.com.ar> References: <4DF291D0.7080707@gont.com.ar> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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 , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 01:15:54 -0000 Hi Fernando, On Fri, 10 Jun 2011 18:51:12 -0300 Fernando Gont wrote: > Hi, > > Some folks have expressed (both on-list and off-list) that they would > prefer a less agressive solution for the RA-Guard evasion vulnerability. > So I'd like to hear comments about the possible alternatives.. > > The current I-Ds (draft-gont-6man-nd-extension-headers and > draft-gont-v6ops-ra-guard-evasion) basically take this approach: > > * Prohibit use of extension headers in ND messages. A host > implementation must not produce these packets, and must discard them if > it receives them > * This results in a RA-Guard implementation that is as simple as > possible (it only has to look at the header following the fixed IPv6 > header). > If changing host implementations is an option, then a simpler idea might be to have RAs come from a source address from within a well-known range of link-local addresses. The 11th to 16th bits (or more) after the fe80 in the link local address could be used to indicate the type of address e.g. fe80::/16 - hosts and "legacy untyped" link local address use fe81::/16 - neighbor discovery address resolution fe82::/16 - router functions e.g. RAs, ICMPv6 redirects fe83::/16 - dhcpv6 server functions fe84::/16 - RIP messages and next-hops fe85::/16 - OSPF messages and next-hops fe86::/16 - IS-IS next hop fe87::/16 - BGP messages and next-hops etc. (I'm not sure if the routing protocol ones would be useful) so a device acting as a router, a dhcpv6-server and an host would have 3 link local addresses, using each different one for the corresponding function as a source address e.g. fe80::1 - normal link-local unicast communications fe81::1 - neighbor discovery address resolution functions fe82::1 - router related functions (RAs, ND redirects) fe83::1 - dhcpv6 server related functions I'd think "RA guard" type filtering would then be pretty easy in layer 2 devices, as these bits have a fixed location in the IPv6 header, and the filtering would be a binary match on a 16 bit value. For a switch interface facing a router, the switch would only accept fe80::16, fe81::/16 and fe82::/16 link local source addresses. For a switch interface facing a host, the switch would only accept fe80::16 and fe81::/16. Some IPv6 switches today are able to implement basic ACLs including source IPv6 addresses, so once the devices providing these functions are using these typed source addresses, there would be an option of implementing this sort of checking today for a number of people. I think the key advantage to this idea is that very little intensive packet checking has to occur before a forward/drop decision can be made. Hosts would have to implement these checks too. Until they're implemented in the IPv6 stack, an interim option would be to use the host's IPv6 firewall to perform these source address type checks. E.g., to only accept RAs from an allowed router, check the RA came from a link-local address with fe82::/16 in it's source address. I think the only outstanding issue might be is whether existing IPv6 implementations will allow or accept non-fe80::/16 link local source and destination addresses addresses until their IPv6 stacks are updated. I think it is possible that they would, as long as they aren't checking the values of the 54 zero bits between /10 and /64 in today's link local addresses. I don't have access to much of a test environment at the moment as I'm between jobs, so I'm limited to what I can test with a few Linux boxes. Encoding a device type or function in network layer addresses isn't a new idea, IIRC in appletalk they had clients use the lower 0 - 127 node addresses and servers use the higher 128 - 255 addresses on a cable number. Regards, Mark. > > A more relaxed approach would be as follows: > * Extension headers are allowed with ND messages. > * If the packet is fragmented, the upper-layer header (ICMPv6 in this > case) must be present in the first fragment (i.e., hosts must not > generate packets that violate this requirement, and must discard them if > they receive them). > * Possibly have the RA-Guard box enforce a limit on the maximum number > of extension headers that it will process (e.g., if after jumping to > the, say 10th header the upper-layer header is not found, drop the packet) > * This approach is less aggressive than the one proposed in the > aforementioned I-Ds (i.e., more flexibility), but of course would also > mean that the RA-Guard implementation would need to follow the header > chain, thus leading to increased complexity, and possible performance > issues. > > Any comments/thoughts will be very much appreciated. > > 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 > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ipng@69706e6720323030352d30312d31340a.nosense.org Fri Jun 10 18:51:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B236311E80DF; Fri, 10 Jun 2011 18:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6T8UdeDT78w; Fri, 10 Jun 2011 18:51:41 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id A569811E80A3; Fri, 10 Jun 2011 18:51:38 -0700 (PDT) Received: from 219-90-139-83.ip.adam.com.au ([219.90.139.83] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QVDMJ-0005OJ-6e; Sat, 11 Jun 2011 11:21:31 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id BA3A93B338; Sat, 11 Jun 2011 11:21:30 +0930 (CST) Date: Sat, 11 Jun 2011 11:21:30 +0930 From: Mark Smith To: Mark Smith Message-ID: <20110611112130.1ad58133@opy.nosense.org> In-Reply-To: <20110611104537.40918bcd@opy.nosense.org> References: <4DF291D0.7080707@gont.com.ar> <20110611104537.40918bcd@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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 , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 01:51:41 -0000 On Sat, 11 Jun 2011 10:45:37 +0930 Mark Smith wrote: > Hi Fernando, > > > On Fri, 10 Jun 2011 18:51:12 -0300 > Fernando Gont wrote: > > > Hi, > > > > Some folks have expressed (both on-list and off-list) that they would > > prefer a less agressive solution for the RA-Guard evasion vulnerability. > > So I'd like to hear comments about the possible alternatives.. > > > > The current I-Ds (draft-gont-6man-nd-extension-headers and > > draft-gont-v6ops-ra-guard-evasion) basically take this approach: > > > > * Prohibit use of extension headers in ND messages. A host > > implementation must not produce these packets, and must discard them if > > it receives them > > * This results in a RA-Guard implementation that is as simple as > > possible (it only has to look at the header following the fixed IPv6 > > header). > > > > If changing host implementations is an option, then a simpler idea > might be to have RAs come from a source address from within a well-known > range of link-local addresses. The 11th to 16th bits (or more) after > the fe80 in the link local address could be used to indicate the type > of address e.g. > > fe80::/16 - hosts and "legacy untyped" link local address use > fe81::/16 - neighbor discovery address resolution > fe82::/16 - router functions e.g. RAs, ICMPv6 redirects > fe83::/16 - dhcpv6 server functions > fe84::/16 - RIP messages and next-hops > fe85::/16 - OSPF messages and next-hops > fe86::/16 - IS-IS next hop > fe87::/16 - BGP messages and next-hops > etc. > > (I'm not sure if the routing protocol ones would be useful) > > so a device acting as a router, a dhcpv6-server and an host would > have 3 link local addresses, using each different one for the ^ should be 4, realised that there probably would be value in having a separate category for neighbor discovery address resolution while writing the email, a few similar related errors below. > corresponding function as a source address e.g. > > fe80::1 - normal link-local unicast communications > fe81::1 - neighbor discovery address resolution functions > fe82::1 - router related functions (RAs, ND redirects) > fe83::1 - dhcpv6 server related functions > > I'd think "RA guard" type filtering would then be pretty easy in layer > 2 devices, as these bits have a fixed location in the IPv6 header, and > the filtering would be a binary match on a 16 bit value. For a > switch interface facing a router, the switch would only accept > fe80::16, fe81::/16 and fe82::/16 link local source addresses. should have been fe80::/16, fe81::/16, fe82::/16 and fe83::/16 > For a > switch interface facing a host, the switch would only accept fe80::16 fe80::/16 > and fe81::/16. Some IPv6 switches today are able to implement basic > ACLs including source IPv6 addresses, so once the devices providing > these functions are using these typed source addresses, there would be > an option of implementing this sort of checking today for a number of > people. I think the key advantage to this idea is that very little > intensive packet checking has to occur before a forward/drop decision > can be made. > > Hosts would have to implement these checks too. Until they're > implemented in the IPv6 stack, an interim option would be to use the > host's IPv6 firewall to perform these source address type checks. E.g., > to only accept RAs from an allowed router, check the RA came from a > link-local address with fe82::/16 in it's source address. > > I think the only outstanding issue might be is whether existing IPv6 > implementations will allow or accept non-fe80::/16 link local > source and destination addresses addresses until their IPv6 stacks are > updated. I think it is possible that they would, as long as they aren't > checking the values of the 54 zero bits between /10 and /64 in today's > link local addresses. I don't have access to much of a test environment > at the moment as I'm between jobs, so I'm limited to what I can test > with a few Linux boxes. > > Encoding a device type or function in network layer addresses isn't a > new idea, IIRC in appletalk they had clients use the lower 0 - 127 node > addresses and servers use the higher 128 - 255 addresses on a cable > number. > > > Regards, > Mark. > > > From pch-b2B3A6689@u-1.phicoh.com Sat Jun 11 01:10:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214C711E8078; Sat, 11 Jun 2011 01:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrwcqzuWfqiC; Sat, 11 Jun 2011 01:10:12 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDAE11E8081; Sat, 11 Jun 2011 01:09:43 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QVJG6-0001gzC; Sat, 11 Jun 2011 10:09:30 +0200 Message-Id: To: Fernando Gont From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Fri, 10 Jun 2011 18:51:12 -0300 ." <4DF291D0.7080707@gont.com.ar> Date: Sat, 11 Jun 2011 10:09:15 +0200 Cc: IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 08:10:13 -0000 In your letter dated Fri, 10 Jun 2011 18:51:12 -0300 you wrote: >A more relaxed approach would be as follows: >* Extension headers are allowed with ND messages. >* If the packet is fragmented, the upper-layer header (ICMPv6 in this >case) must be present in the first fragment (i.e., hosts must not >generate packets that violate this requirement, and must discard them if >they receive them). >* Possibly have the RA-Guard box enforce a limit on the maximum number >of extension headers that it will process (e.g., if after jumping to >the, say 10th header the upper-layer header is not found, drop the packet) >* This approach is less aggressive than the one proposed in the >aforementioned I-Ds (i.e., more flexibility), but of course would also >mean that the RA-Guard implementation would need to follow the header >chain, thus leading to increased complexity, and possible performance >issues. Strikes me as a bad tradeoff. This requires all L2 switches to parse IPv6 extension headers at wire speed. So, some of them will get it wrong. And the only benefit menioned in the discussion so far is the need to send RAs large enough that they need to be fragmented. Another benefit would be that you don't have to change host software. From bob.hinden@gmail.com Sat Jun 11 08:02:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E2C21F84B9; Sat, 11 Jun 2011 08:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_BEZEQINT_B=0.763, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8mhRNIgKjOt; Sat, 11 Jun 2011 08:02:15 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E748E21F84B6; Sat, 11 Jun 2011 08:02:14 -0700 (PDT) Received: by pwi5 with SMTP id 5so1766029pwi.31 for ; Sat, 11 Jun 2011 08:02:14 -0700 (PDT) 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=trqkdDY7nYdLGbQnJDjULwsKj299c4iYmimqGrFvOTY=; b=rtg96Bd2GmnxpZLEMdMtikOYW3/yCrLaueqq5bEYo+H3pcF+sLzhj6/3EA7Hg8uwJ9 KravY4beQwJt59w0DCnnrkRfqlop5wCNtWuclxHJjcpaflezpFSt7GMm6tzRCX4lZ12z HYc6tlCr/5z/eQYc7Sj2EMjt0+cneLMXQCGEQ= 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=vDxj5lNJ5vNJRvkd3pkD4TBixvIG/jl90B/B32QMDcV34YFzNgP3KfTcaqqPsl4HLR Hj6lUUPQAyIZ5/jQqL0GaO0RaqijC/ZnkOE1nOzJDNQRdeC5juhiH3s/2qhp8KFUtLK/ nZlr0CPRWu/AmB7vd/ggmX9h6ZyIBB/wKVYeY= Received: by 10.143.92.21 with SMTP id u21mr664116wfl.399.1307804534511; Sat, 11 Jun 2011 08:02:14 -0700 (PDT) Received: from [192.168.4.204] (bzq-218-39-93.cablep.bezeqint.net [81.218.39.93]) by mx.google.com with ESMTPS id k4sm3188467pbl.43.2011.06.11.08.02.10 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Jun 2011 08:02:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4DF291D0.7080707@gont.com.ar> Date: Sat, 11 Jun 2011 18:02:04 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4B579A55-9973-4454-9BD5-256094ED3FC3@gmail.com> References: <4DF291D0.7080707@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: "ipv6@ietf.org" , IPv6 Operations Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 15:02:15 -0000 Fernando, On Jun 11, 2011, at 12:51 AM, Fernando Gont wrote: > Hi, >=20 > Some folks have expressed (both on-list and off-list) that they would > prefer a less agressive solution for the RA-Guard evasion = vulnerability. > So I'd like to hear comments about the possible alternatives.. >=20 > The current I-Ds (draft-gont-6man-nd-extension-headers and > draft-gont-v6ops-ra-guard-evasion) basically take this approach: >=20 > * Prohibit use of extension headers in ND messages. A host > implementation must not produce these packets, and must discard them = if > it receives them > * This results in a RA-Guard implementation that is as simple as > possible (it only has to look at the header following the fixed IPv6 > header). What is a use case where extension headers would be used in ND (ICMPv6) = messages? Same for Fragmentation? =20 I am having a hard time thinking of any, so I like your approach. = Unless I am missing something. Thanks, Bob >=20 >=20 > A more relaxed approach would be as follows: > * Extension headers are allowed with ND messages. > * If the packet is fragmented, the upper-layer header (ICMPv6 in this > case) must be present in the first fragment (i.e., hosts must not > generate packets that violate this requirement, and must discard them = if > they receive them). > * Possibly have the RA-Guard box enforce a limit on the maximum number > of extension headers that it will process (e.g., if after jumping to > the, say 10th header the upper-layer header is not found, drop the = packet) > * This approach is less aggressive than the one proposed in the > aforementioned I-Ds (i.e., more flexibility), but of course would also > mean that the RA-Guard implementation would need to follow the header > chain, thus leading to increased complexity, and possible performance > issues. >=20 > Any comments/thoughts will be very much appreciated. >=20 > Thanks! >=20 > Best regards, > --=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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fernando.gont.netbook.win@gmail.com Sun Jun 12 04:00:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8669011E8096; Sun, 12 Jun 2011 04:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIEz2Nn1P2bq; Sun, 12 Jun 2011 04:00:10 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0FF11E8092; Sun, 12 Jun 2011 04:00:09 -0700 (PDT) Received: by wyb29 with SMTP id 29so3071870wyb.31 for ; Sun, 12 Jun 2011 04:00:08 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=hR6Bglf5ujR84G7P4qrRuCBes8RLK2zK4+zrUKHbJuw=; b=oOT6a7x73b8Hr5O0BC0qA9CKTR8BWzUlusfoUr/RQHFYmam4qAEqQu2CenDJVjRAYA M3VEBT7kb3Mb9tb/HqETD/NOwZ9Fb/+APCrv9KUivxoZUTBcMbD6e2wDYhx/4NLYDYh7 kIrlhvG+HASukt35VLWFjBg5thiKT8lTvg0rE= 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:content-type :content-transfer-encoding; b=RXUaw483BbSEcJ5nkY+OApxav/sqSH49BEgU8rB/nofeIpzdlgyu0YdZR5eKDkjvkQ CYxT2glwDt4UprwoFK54NJSk8jzwB+riHtyhzSN+uh6SHOB535nOH1AvBbX34WcxMKZR RoQGWM5LinLah8TzkMMtattg7DzhdgMhEUb6I= Received: by 10.216.30.206 with SMTP id k56mr1561890wea.29.1307876408212; Sun, 12 Jun 2011 04:00:08 -0700 (PDT) Received: from [192.168.101.204] ([213.174.121.108]) by mx.google.com with ESMTPS id gb6sm3409060wbb.0.2011.06.12.04.00.06 (version=SSLv3 cipher=OTHER); Sun, 12 Jun 2011 04:00:07 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DF3D711.6@gont.com.ar> Date: Sat, 11 Jun 2011 17:58:57 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Smith References: <4DF291D0.7080707@gont.com.ar> <20110611104537.40918bcd@opy.nosense.org> <20110611112130.1ad58133@opy.nosense.org> In-Reply-To: <20110611112130.1ad58133@opy.nosense.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 11:00:10 -0000 Hi, Mark, On 06/10/2011 10:51 PM, Mark Smith wrote: >> If changing host implementations is an option, then a simpler idea >> might be to have RAs come from a source address from within a well-known >> range of link-local addresses. The 11th to 16th bits (or more) after >> the fe80 in the link local address could be used to indicate the type >> of address e.g. This might help with attack vectors based on forged RAs, but not with other vectors (e.g., forged Neighbor Advertisements). Also, your proposal modifies the addressing architecture -- while this is not "per se" a bad thing this is a more radical change than the one proposed in my I-D (which, as far as legitimate traffic is concerned, is a no-op, since extension headers with ND are not used for any legitimate purpose). >> (I'm not sure if the routing protocol ones would be useful) >> >> so a device acting as a router, a dhcpv6-server and an host would >> have 3 link local addresses, using each different one for the > ^ > should be 4, realised that there probably would be value in having a > separate category for neighbor discovery address resolution while > writing the email, a few similar related errors below. If you don't prevent the use of extension headers for ND (in particular, of the Fragment Header) it's still very painful to perform any kind of monitoring on the Neighbor Discovery traffic (e.g., with NDPMon and the like). >> and fe81::/16. Some IPv6 switches today are able to implement basic >> ACLs including source IPv6 addresses, so once the devices providing >> these functions are using these typed source addresses, there would be Note that this would also require an update to routers (which might not be possible), and would also imply a rather radical change for the ops people (which, imo, at this point in time would be a bad thing). But there seems to be an even more substantial problem: this seems to require a flag day. i.e., how do hosts tell if they are receiving "traditional" RAs because they are under attack, or because the network has not yet been upgraded to implement your proposal? >> an option of implementing this sort of checking today for a number of >> people. I think the key advantage to this idea is that very little >> intensive packet checking has to occur before a forward/drop decision >> can be made. If extension headers are prohibited, you only need to look at fixed locations in the packet (IPv6 "Next Header", and then ICMP type). >> Hosts would have to implement these checks too. Until they're >> implemented in the IPv6 stack, an interim option would be to use the >> host's IPv6 firewall to perform these source address type checks. E.g., >> to only accept RAs from an allowed router, check the RA came from a >> link-local address with fe82::/16 in it's source address. But the RA-Guard box would still need to deal with the "traditional" RAs, since there might be legacy hosts that would react to them. >> I think the only outstanding issue might be is whether existing IPv6 >> implementations will allow or accept non-fe80::/16 link local >> source and destination addresses addresses until their IPv6 stacks are >> updated. I think it is possible that they would, as long as they aren't >> checking the values of the 54 zero bits between /10 and /64 in today's >> link local addresses. Oh, yes, they do. :-) KAME discards such packets. 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 fernando.gont.netbook.win@gmail.com Sun Jun 12 04:00:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7441E11E80E2; Sun, 12 Jun 2011 04:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bv-9zKwne3Dr; Sun, 12 Jun 2011 04:00:15 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6959F11E80E1; Sun, 12 Jun 2011 04:00:14 -0700 (PDT) Received: by wwa36 with SMTP id 36so2673992wwa.13 for ; Sun, 12 Jun 2011 04:00:13 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=nfyNU9RYt1dFv51WNHmWVZL4KVlseTpCJpZQ65ZOCwc=; b=Y+CTGiAmeSK6KTUiXuUJMANPBhzNZVFG9MNq/Ng5C9jinvLXv9pkWATkDr0K7S635j cRL1Go/EFevvGvgw6kAfHyb51fYIKYzSPnjQBM+dwF5HZHh4HEHm6PNmNvlOyFKPzGJV KuM5k7omwx9NzdsATsyrz6BGfcZKn18GefayA= 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:content-type :content-transfer-encoding; b=Tmc06Z3o9eTzh/A52YdOcTQWDFmM5DPaMRl1PGqGyFGLZCxXncc9U3RD4RVKSD8PXV vCBJ9n+m2GuLBygqP6cFr+0b+BnbZHYnk8HhJo/9fKWnNR/L3jzgHWbATijXC6HW1cyl ZFNyxsQmWpRemaRNHA1HdrAykNFrlh/aOIu+I= Received: by 10.227.182.74 with SMTP id cb10mr3986866wbb.48.1307876413579; Sun, 12 Jun 2011 04:00:13 -0700 (PDT) Received: from [192.168.101.204] ([213.174.121.108]) by mx.google.com with ESMTPS id c17sm3406527wbh.29.2011.06.12.04.00.11 (version=SSLv3 cipher=OTHER); Sun, 12 Jun 2011 04:00:13 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DF3DAA0.5090206@gont.com.ar> Date: Sat, 11 Jun 2011 18:14:08 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Philip Homburg References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 11:00:15 -0000 On 06/11/2011 05:09 AM, Philip Homburg wrote: >> * Possibly have the RA-Guard box enforce a limit on the maximum number >> of extension headers that it will process (e.g., if after jumping to >> the, say 10th header the upper-layer header is not found, drop the packet) >> * This approach is less aggressive than the one proposed in the >> aforementioned I-Ds (i.e., more flexibility), but of course would also >> mean that the RA-Guard implementation would need to follow the header >> chain, thus leading to increased complexity, and possible performance >> issues. > > Strikes me as a bad tradeoff. This requires all L2 switches to parse IPv6 > extension headers at wire speed. So, some of them will get it wrong. +1 > And the only benefit menioned in the discussion so far is the need to send > RAs large enough that they need to be fragmented. Actually, you can get the same benefit with no fragmentation: just send multiple RAs. > Another benefit would be that you don't have to change host software. I think that, in practice, this is less of an issue. In may cases, this could be an automatic "security update". In others, the hosts may be connected to networks that do not yet support v6, and by the time v6 is deployed on these networks, the corresponding OSes will have already been updated/upgraded. 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 fernando.gont.netbook.win@gmail.com Sun Jun 12 04:00:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C3B11E80EE; Sun, 12 Jun 2011 04:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGlYrnlsSVYF; Sun, 12 Jun 2011 04:00:17 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 21B4A11E80E7; Sun, 12 Jun 2011 04:00:16 -0700 (PDT) Received: by wwk4 with SMTP id 4so1868399wwk.1 for ; Sun, 12 Jun 2011 04:00:16 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=UUmqf+IzgAQXU2Nh21mcxOn6T/2mfIym7bKoeR9rEU4=; b=h8rF+K7Zp4ZZiPhKA4+DrWOlT5jB9jii2yAXsT0NmMbTyQ6TOk38W4SN89vzP9hwBd CrrXFfFz6dPOacn/n+eIijSnb0Qhh4jDbZL19+agh8k2+RWHQoXlQWwOhfW5YlW/ZBbz 2T378T1vL0PLzZOTzYPnHXrsCossNot3mcNcI= 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:content-type :content-transfer-encoding; b=AsGwWNZjcxutCyl42dJvuXK3o3EYxCJKy1AvPFl1jqI07w3tSYA5eeeyqi/ICoPwzQ NB1VW2/7Pv+aFPAsjNnY9nd9EDlVnltC9nyaIlAzA8YP5QaXtWvguG5T8w4nUMZgnucw em5yUo32+bTb5kTNJZo5H5KknTx4p6+ch4G/g= Received: by 10.227.160.11 with SMTP id l11mr3910270wbx.1.1307876416189; Sun, 12 Jun 2011 04:00:16 -0700 (PDT) Received: from [192.168.101.204] ([213.174.121.108]) by mx.google.com with ESMTPS id o19sm3407147wbh.21.2011.06.12.04.00.15 (version=SSLv3 cipher=OTHER); Sun, 12 Jun 2011 04:00:15 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DF3F91A.2080109@gont.com.ar> Date: Sat, 11 Jun 2011 20:24:10 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bob Hinden References: <4DF291D0.7080707@gont.com.ar> <4B579A55-9973-4454-9BD5-256094ED3FC3@gmail.com> In-Reply-To: <4B579A55-9973-4454-9BD5-256094ED3FC3@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extension headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 11:00:18 -0000 Hi, Bob, On 06/11/2011 12:02 PM, Bob Hinden wrote: >> * Prohibit use of extension headers in ND messages. A host >> implementation must not produce these packets, and must discard >> them if it receives them * This results in a RA-Guard >> implementation that is as simple as possible (it only has to look >> at the header following the fixed IPv6 header). > > What is a use case where extension headers would be used in ND > (ICMPv6) messages? I am told that AH could potentially be used with ND. Also, that some high-security sites might want to use CALIPSO with ND. And that there's always the possibility that somebody could come up with with an ND extension/feature that requires IPv6 extension headers. I personally think that when it comes to possible extensions to ND, most of them could be implemented with ND options (rather than extension headers). As for AH or CALIPSO, from my perspective (and if anything) I'd argue that the I-D could require that hosts include a configuration switch that can enable the processing of ND packets with extension headers (such configuration knob would default to "off/disable") -- i.e., for the general case (and by default), ND packets are not allowed to include IPv6 extension headers.. but if you have a specific scenario in which you'd need them (unlikely, from my perspective), you can override this policy such that they are accepted. > Same for Fragmentation? As far as I can tell from Pekka's note, at least radvd does not support fragmentation with ND. So the only *potential* use case is sending (probably insane) amounts of information in RAs -- but you can always send the same amount of information using multiple RAs. > I am having a hard time thinking of any, so I like your approach. I believe the approach currently outlined in the I-Ds keeps things simple and allows for simple RA-guard implementation and ND-monitoring tools like NDPMon. And that's the approach I would prefer to pursue. However, since some had brought up possible alternatives, I wanted others to weigh in. 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 fred@cisco.com Mon Jun 13 11:47:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4882521F863E for ; Mon, 13 Jun 2011 11:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.836 X-Spam-Level: X-Spam-Status: No, score=-110.836 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Legj15wgiagP for ; Mon, 13 Jun 2011 11:47:43 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF6B21F8640 for ; Mon, 13 Jun 2011 11:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4110; q=dns/txt; s=iport; t=1307990863; x=1309200463; h=from:subject:date:references:to:message-id:mime-version: content-transfer-encoding; bh=8SQElIUu58zYo8DsddSRKbpARgLMiPnDkfeu3iQYzks=; b=R66HHm7vXYOcdlzDNKC3iYtmTwCnJNfIWiqzdxThTMV0lpE2K6oqiOnr xc724dY1UmcZvTaA7tJBLkVHhXewjuJBCfDSbFRV9BRENGNrxqMmZG5y+ tG41iw8K752LV50AjCY1J+TmaAjvdnDvoAvcqF8PjFgGxV8nQcXhzoTT0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMBa9k2rRDoJ/2dsb2JhbAA1HaYud6pYjniBcIRMiDGGJASHDYonhE+LLg X-IronPort-AV: E=Sophos;i="4.65,359,1304294400"; d="scan'208";a="464652875" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 13 Jun 2011 18:47:20 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5DIlEfn014371 for ; Mon, 13 Jun 2011 18:47:20 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 13 Jun 2011 11:47:20 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 13 Jun 2011 11:47:20 -0700 From: Fred Baker Date: Mon, 13 Jun 2011 11:47:04 -0700 References: To: "v6ops@ietf.org Working Group" Message-Id: <04E47162-749D-43FF-89E4-5EBBAFB9DA1A@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [v6ops] Fwd: Nomcom 2011-12: Call for Volunteers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 18:47:44 -0000 > -------- Original Message -------- > Subject: Nomcom 2011-12: Call for Volunteers > Date: Fri, 10 Jun 2011 19:56:06 -0700 (PDT) > From: NomCom Chair > To: IETF Announcement list > > The IETF nominating committee process for 2011-12 has begun. The IETF > nominating committee appoints folks to fill the open slots on the > IAOC, the IAB, and the IESG. The 10 nominating committee members are > selected randomly from a pool of volunteers. The more volunteers, the > better the chance we have of choosing a random yet representative > cross section of the IETF population. The details of the nomcom > process can be found in RFC 3777. > > To be eligible, volunteers for the nomcom need to have attended 3 of > the past 5 IETF meetings as of the time this announcement goes out > (i.e. IETF76-IETF80). If you qualify, and are not seeking appointment > to any of the open positions this nomcom will be filling, please > consider volunteering. > > The list of people and posts whose terms end with the March 2012 IETF > meeting, and thus the positions for which the nominating committee is > responsible, are as follows: > > IAB > === > > Bernard Aboba > Hannes Tschofenig > Andrei Robachevsky > Olaf Kolkman > Spencer Dawkins > Ross Callon > > IAOC > ==== > > Marshall Eubanks > > IESG > ==== > > Peter Saint-Andre (Applications) > Jari Arkko (Internet) > Dan Romascanu (Operations & Management) > Gonzalo Camarillo (RAI) > Stewart Bryant (Routing) > Sean Turner (Security) > David Harrington (Transport) > > > The primary activity for this nomcom will begin during IETF-81 in > Quebec City and should be completed by January 2012. The nomcom will > be collecting requirements from the community, as well as talking to > candidates and to community members about candidates. There will be > regularly scheduled conference calls to ensure progress. Thus, being a > nomcom member does require some time commitment. > > Please volunteer by sending an email to me before > 11:59 pm EDT July 10, 2011 as follows: > > To: suresh.krishnan@ericsson.com > Subject: Nomcom 2011-12 Volunteer > > Please include the following information in the body of the mail: > > Full Name: // As you enter in the IETF Registration Form, > // First/Given name followed by Last/Family Name > > Current Primary Affiliation: // typically what goes in the Company > // field in the IETF Registration Form > > Email Address(es): // all email addresses used to Register for the > // past 5 IETF meetings > // Please designate a Preferred email address for > // contact if there is more than one email address > > Telephone number: // With country code (for confirmation if selected) > > Please expect an email response from me within 3 business days stating > whether or not you are qualified. If you do not receive a response in > this timeframe, please re-send your email with the tag "RESEND:" added > to the subject line. > > If you are not yet sure you would like to volunteer, please consider > that nomcom members play a very important role in shaping the > leadership of the IETF. Ensuring the leadership of the IETF is fair > and balanced and comprised of those who can lead the IETF in the right > direction is an important responsibility that rests on the IETF > participants at large. Volunteering for the nomcom is a good way of > contributing in that direction. > > I will be publishing a more detailed target timetable, as well as > details of the randomness seeds to be used for the RFC 3797 selection > process within the next few days. > > Thank you in advance for your participation. > > Suresh Krishnan > Nomcom Chair 2011-2012 > Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From nick@inex.ie Mon Jun 13 15:39:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABD211E809F; Mon, 13 Jun 2011 15:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vm9+3HekHUxB; Mon, 13 Jun 2011 15:39:16 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [46.182.8.5]) by ietfa.amsl.com (Postfix) with ESMTP id B7A4211E8070; Mon, 13 Jun 2011 15:39:15 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.foobar.org (twinkie.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id p5DMcu9R036534 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 13 Jun 2011 23:39:01 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4DF69180.6050902@inex.ie> Date: Mon, 13 Jun 2011 23:38:56 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110528 Thunderbird/5.0b1 MIME-Version: 1.0 To: Fernando Gont References: <4DF291D0.7080707@gont.com.ar> In-Reply-To: <4DF291D0.7080707@gont.com.ar> X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 22:39:17 -0000 On 10/06/2011 22:51, Fernando Gont wrote: > * This results in a RA-Guard implementation that is as simple as > possible (it only has to look at the header following the fixed IPv6 > header). dhcpv6 suffers from exactly the same problem. Are there plans to introduce dhcpv6-guard? Nick From Ted.Lemon@nominum.com Mon Jun 13 15:44:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7BD21F8491; Mon, 13 Jun 2011 15:44:39 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbXsOIHujFSJ; Mon, 13 Jun 2011 15:44:35 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id CE9D921F8492; Mon, 13 Jun 2011 15:44:34 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTfaS0fvgg+1R8c/ywz0EFpIW3DEOwxD6@postini.com; Mon, 13 Jun 2011 15:44:34 PDT 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 4BF15F8042; Mon, 13 Jun 2011 15:44:33 -0700 (PDT) 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 ESMTPS id 41788190058; Mon, 13 Jun 2011 15:44:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from kali.ddns.nominum.com (64.89.225.121) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 13 Jun 2011 15:44:33 -0700 MIME-Version: 1.0 (Apple Message framework v1237.1) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4DF69180.6050902@inex.ie> Date: Mon, 13 Jun 2011 15:44:32 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <701DCBC2-E1B6-420A-B258-504589335A20@nominum.com> References: <4DF291D0.7080707@gont.com.ar> <4DF69180.6050902@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1237.1) Cc: IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 22:44:39 -0000 On Jun 13, 2011, at 3:38 PM, Nick Hilliard wrote: > dhcpv6 suffers from exactly the same problem. Are there plans to = introduce dhcpv6-guard? Nobody's proposed it. From stephen.farrell@cs.tcd.ie Mon Jun 13 16:09:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEF8228011; Mon, 13 Jun 2011 16:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.183 X-Spam-Level: X-Spam-Status: No, score=-106.183 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQo6OWhbZy3L; Mon, 13 Jun 2011 16:09:32 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id A3152228010; Mon, 13 Jun 2011 16:09:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 10013171C57; Tue, 14 Jun 2011 00:09:28 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308006564; bh=2M+MRdBDcYEi+w uymS+lhd6/LQM/EloQMaEtcwOBKK0=; b=XocrV9AIVVQ53tuk/v7lL8rFH88TDm PyDbEB4R/N2TPwGux3n8DMoLN7Pc4j2UECg5iceaSfE3qgISHMpFndoNka2zVwh7 ptRUU3kq/HUfLz14+UoU8Km5sPp6pNb9CAh2NV2PgY7Nmo2PfPDp8Ri533EpZe8F VwUSLd6pmiTULnHpKYykYDb+JFFWqnLDAAJpVRpirlr67R4+5Ndc7C2ggQxKU6QI BTtAhtTRaAu3fSrMttGii8ILx/9yL8IH+P9KldYJfJjC+2WWnYwwqAydL2mTUuWJ t1bN8I1zkyrnmdDuEJb/uoukxtLnEUu8cxAH/fnxP+lMUPo7RCe5Mzkg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id TV7xFrezEjkZ; Tue, 14 Jun 2011 00:09:24 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.18.245]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3E613171C2D; Tue, 14 Jun 2011 00:09:24 +0100 (IST) Message-ID: <4DF69899.2050606@cs.tcd.ie> Date: Tue, 14 Jun 2011 00:09:13 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Farrell References: <4DEA6323.4070302@cs.tcd.ie> In-Reply-To: <4DEA6323.4070302@cs.tcd.ie> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 23:09:33 -0000 All, Thanks for the feedback on this liaison. Eliot (mostly) and I (a bit) have tried to capture all that in the text below. Please send any comments on that (with specific alternative text) in the next week and then we'll shoot it on to them. RFC 3514 does have some words about IPv6 - should I add that as a reference? :-) Thanks, Stephen. From: IETF Security Area To: Study Group 17, Questions 2 and 3 Title: Work on Security of IPv6 FOR ACTION The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 security issues". As the world transitions to IPv6, new opportunities and challenges and challenges arise. SG17's new focus on deployment and implementation considerations reflects this reality. We would like to bring to your attention the following work which we believe may prove a useful basis for both X.ipv6-secguide and X.mgv6: * RFC 4294 – "IPv6 Node Requirements" (N.B., this work is currently under revision) * draft-ietf-6man-node-req-bis (work in progress) – "IPv6 Node Requirements RFC 4294-bis" * RFC 4864 – "Local Network Protection for IPv6" * RFC 6092 – "Recommended Simple Security Capabilities in Customer Premise Equipment (CPE) for Providing Residential IPv6 Internet Service" * RFC 6105 – "IPv6 Router Advertisement Guard" * RFC 6106 – "IPv6 Router Advertisement Options for DNS Configuration", §7 in particular. As you are aware, every RFC contains a Security Considerations section. In developing either a implementation or deployment guide, contributors are strongly encouraged to review the RFCs and Internet-Drafts that support any underlying function. In addition, we bring to your attention the following IETF Working Groups that are working on security-related work of IPv6: Working Group Purpose Mailing list address Name 6man IPv6 Maintenance ipv6@ietf.org savi Source Address Validation savi@ietf.org Improvements dhc Dynamic Host Configuration dhcwg@ietf.org v6ops IPv6 Operations v6ops@ietf.org opsec Operational Security opsec@ietf.org Capabilities for an IP Network In addition to the above working groups, the Security Area of the IETF maintains a mailing list for general discussion, saag@ietf.org. We encourage and invite open and informal discussion in these or other relevant IETF fora on this very important topic. As with all IETF working groups, any and all interested parties can choose to directly contribute via the mailing lists above. As in other areas, the Security Area of the IETF invites SG17 to bring any new-found concerns about IETF protocols to our attention so that as and when we revise our documents we can make appropriate amendments to IETF protocols. In particular, as this planned work matures, we would welcome hearing about it in more detail, perhaps via an invited presentation at a saag meeting or via review of draft documents as may be appropriate. From stephen.farrell@cs.tcd.ie Mon Jun 13 17:01:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4ED321F8479; Mon, 13 Jun 2011 17:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.137 X-Spam-Level: X-Spam-Status: No, score=-106.137 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF9AVgqOyG62; Mon, 13 Jun 2011 17:01:28 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id C8A9321F8478; Mon, 13 Jun 2011 17:01:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EADA1171C57; Tue, 14 Jun 2011 01:01:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308009683; bh=5brO03To29fhYd a07P2lJXC4KlbotzYy3H/AyOFPMvI=; b=qZt/PET7ZAxj8DkKgTGHIbGJ9tTFzM LKMYDCrZHssLdzupGCVfsRd7F6o0i9OrdgEZgCXBQa5YPb14k/Cv/CaaAoGh5N0l BPrSZx4k+LxZnLdYQ9jQ2a4J0uAHW6s/+6G9RelCis4qK5goaj5htY1CUTjnC5O3 zW9tG/n7Ki513g1FWAVLDpdSK5fXpJpoiF6Y7zE0kL6wyBZEe1VXRiiI9yZea2gB 7Guc0YOoX+BgSvxsQdYj1Wfcmbm0fppenhd4WHrLnIuwoOxHt5g7CTueKATRBLPF 48lEEW+Jr0FFL+tAVKthdOAcKJOgVKo5rMWGQNcn57Za3tHhiWPN24mg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id UIGQ1gVqZRlH; Tue, 14 Jun 2011 01:01:23 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.18.245]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6417A171C2D; Tue, 14 Jun 2011 01:01:23 +0100 (IST) Message-ID: <4DF6A4D2.9060306@cs.tcd.ie> Date: Tue, 14 Jun 2011 01:01:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Russ Housley References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 00:01:28 -0000 Thanks Russ, will make those changes. S. On 14/06/11 00:57, Russ Housley wrote: > Stephen: > > Comments below. > > Russ > > >> From: IETF Security Area >> To: Study Group 17, Questions 2 and 3 >> Title: Work on Security of IPv6 >> >> FOR ACTION >> >> The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 >> security issues". As the world transitions to IPv6, new opportunities >> and challenges and challenges arise. SG17's new focus on deployment and > > s/and challenges and challenges/and challenges/ > s/new// > >> implementation considerations reflects this reality. We would like to >> bring to your attention the following work which we believe may prove a >> useful basis for both X.ipv6-secguide and X.mgv6: >> >> * RFC 4294 – "IPv6 Node Requirements" (N.B., this work is currently >> under revision) > > Why not just reference the bis document? > >> * draft-ietf-6man-node-req-bis (work in progress) – "IPv6 Node >> Requirements RFC 4294-bis" >> * RFC 4864 – "Local Network Protection for IPv6" >> * RFC 6092 – "Recommended Simple Security Capabilities in Customer >> Premise Equipment (CPE) for Providing Residential IPv6 Internet >> Service" >> * RFC 6105 – "IPv6 Router Advertisement Guard" >> * RFC 6106 – "IPv6 Router Advertisement Options for DNS >> Configuration", §7 in particular. >> >> As you are aware, every RFC contains a Security Considerations section. >> In developing either a implementation or deployment guide, contributors >> are strongly encouraged to review the RFCs and Internet-Drafts that >> support any underlying function. >> >> In addition, we bring to your attention the following IETF Working >> Groups that are working on security-related work of IPv6: >> >> Working Group Purpose Mailing list address >> Name >> >> 6man IPv6 Maintenance ipv6@ietf.org >> savi Source Address Validation savi@ietf.org >> Improvements >> dhc Dynamic Host Configuration dhcwg@ietf.org >> v6ops IPv6 Operations v6ops@ietf.org >> opsec Operational Security opsec@ietf.org >> Capabilities for an IP >> Network >> >> In addition to the above working groups, the Security Area of the IETF >> maintains a mailing list for general discussion, saag@ietf.org. We >> encourage and invite open and informal discussion in these or other >> relevant IETF fora on this very important topic. As with all IETF >> working groups, any and all interested parties can choose to directly >> contribute via the mailing lists above. >> >> As in other areas, the Security Area of the IETF invites SG17 to bring >> any new-found concerns about IETF protocols to our attention so that as >> and when we revise our documents we can make appropriate amendments to >> IETF protocols. In particular, as this planned work matures, we would >> welcome hearing about it in more detail, perhaps via an invited >> presentation at a saag meeting or via review of draft documents as may >> be appropriate. > > From housley@vigilsec.com Mon Jun 13 16:57:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75419E800E; Mon, 13 Jun 2011 16:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.158 X-Spam-Level: X-Spam-Status: No, score=-102.158 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vfn96rGnbGjm; Mon, 13 Jun 2011 16:57:52 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 356ED9E8007; Mon, 13 Jun 2011 16:57:52 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 86079F241CB; Mon, 13 Jun 2011 19:58:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 2zCri2Y+0vBM; Mon, 13 Jun 2011 19:57:50 -0400 (EDT) Received: from v234.vpn.iad.rg.net (v234.vpn.iad.rg.net [198.180.150.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 5A1EDF24166; Mon, 13 Jun 2011 19:58:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Russ Housley In-Reply-To: <4DF69899.2050606@cs.tcd.ie> Date: Mon, 13 Jun 2011 19:57:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 13 Jun 2011 17:26:30 -0700 Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 23:57:53 -0000 Stephen: Comments below. Russ > From: IETF Security Area > To: Study Group 17, Questions 2 and 3 > Title: Work on Security of IPv6 >=20 > FOR ACTION >=20 > The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 > security issues". As the world transitions to IPv6, new opportunities > and challenges and challenges arise. SG17's new focus on deployment = and s/and challenges and challenges/and challenges/ s/new// > implementation considerations reflects this reality. We would like = to > bring to your attention the following work which we believe may prove = a > useful basis for both X.ipv6-secguide and X.mgv6: >=20 > * RFC 4294 =96 "IPv6 Node Requirements" (N.B., this work is = currently > under revision) Why not just reference the bis document? > * draft-ietf-6man-node-req-bis (work in progress) =96 "IPv6 Node > Requirements RFC 4294-bis" > * RFC 4864 =96 "Local Network Protection for IPv6" > * RFC 6092 =96 "Recommended Simple Security Capabilities in = Customer > Premise Equipment (CPE) for Providing Residential IPv6 Internet > Service" > * RFC 6105 =96 "IPv6 Router Advertisement Guard" > * RFC 6106 =96 "IPv6 Router Advertisement Options for DNS > Configuration", =A77 in particular. >=20 > As you are aware, every RFC contains a Security Considerations = section. > In developing either a implementation or deployment guide, = contributors > are strongly encouraged to review the RFCs and Internet-Drafts that > support any underlying function. >=20 > In addition, we bring to your attention the following IETF Working > Groups that are working on security-related work of IPv6: >=20 > Working Group Purpose Mailing list address > Name >=20 > 6man IPv6 Maintenance ipv6@ietf.org > savi Source Address Validation savi@ietf.org > Improvements > dhc Dynamic Host Configuration dhcwg@ietf.org > v6ops IPv6 Operations v6ops@ietf.org > opsec Operational Security opsec@ietf.org > Capabilities for an IP > Network >=20 > In addition to the above working groups, the Security Area of the IETF > maintains a mailing list for general discussion, saag@ietf.org. We > encourage and invite open and informal discussion in these or other > relevant IETF fora on this very important topic. As with all IETF > working groups, any and all interested parties can choose to directly > contribute via the mailing lists above. >=20 > As in other areas, the Security Area of the IETF invites SG17 to bring > any new-found concerns about IETF protocols to our attention so that = as > and when we revise our documents we can make appropriate amendments to > IETF protocols. In particular, as this planned work matures, we would > welcome hearing about it in more detail, perhaps via an invited > presentation at a saag meeting or via review of draft documents as may > be appropriate. From fernando.gont.netbook.win@gmail.com Mon Jun 13 19:04:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F8521F85B5; Mon, 13 Jun 2011 19:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6sqItt+jzCt; Mon, 13 Jun 2011 19:04:03 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFA1821F85B0; Mon, 13 Jun 2011 19:04:02 -0700 (PDT) Received: by wyb29 with SMTP id 29so4131316wyb.31 for ; Mon, 13 Jun 2011 19:04:02 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=Kj/7qrMuzXyGd4+3Q1fZJ5x7MHvhu+NzEY13BkZNomM=; b=RZNxU27bDKox+nL7MKSlTv91MiWX6gGI5m1W1xSuqVMAkMJl00pA7O23duAxf1lmO1 9BZ36fQJgfNz/KBcZcxP1r/ArmrI+73bR7JETewshrm1ykAMIYsYrNc9lR1JamEy0QcX GJzJED5dhrDjMUDhNVzHXl/VdzG1lxZMVvZ84= 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:content-type :content-transfer-encoding; b=wAKbEljEe2apg+KRZxUJ8J+p3YqFwHi0Mj9JrQIz9iuTRDKukMQc5o+y3gcEjipKs4 Ky4ZmD6eqi2sjc8pygZPdCtZFzmTbDvcOfcaxleWdtsA3uVBp2vsxIuYsu5u9Mh8GehW DpFMZHTSr1+aJqeEDyf4um9/xxuD3ye1gFBoE= Received: by 10.216.136.67 with SMTP id v45mr124432wei.106.1308017042002; Mon, 13 Jun 2011 19:04:02 -0700 (PDT) Received: from [172.18.16.182] ([81.253.1.188]) by mx.google.com with ESMTPS id m8sm4648212wbh.62.2011.06.13.19.04.00 (version=SSLv3 cipher=OTHER); Mon, 13 Jun 2011 19:04:01 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DF6B804.4040703@gont.com.ar> Date: Mon, 13 Jun 2011 22:23:16 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nick Hilliard References: <4DF291D0.7080707@gont.com.ar> <4DF69180.6050902@inex.ie> In-Reply-To: <4DF69180.6050902@inex.ie> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 02:04:04 -0000 On 06/13/2011 07:38 PM, Nick Hilliard wrote: > On 10/06/2011 22:51, Fernando Gont wrote: >> * This results in a RA-Guard implementation that is as simple as >> possible (it only has to look at the header following the fixed IPv6 >> header). > > dhcpv6 suffers from exactly the same problem. Agreed. This is noted in the I-D, by the way. > Are there plans to introduce dhcpv6-guard? This is something that vendors should answer. As long as there are implementations that may try DHCPv6 even if no RA is received, DHCPv6 should be implemented/deployed along RA-Guard, or else attackers will switch to teh DHCPv6 vector, and RA-Guard will be circumvented this way. 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 wwwrun@rfc-editor.org Mon Jun 13 20:50:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BFA21F8540; Mon, 13 Jun 2011 20:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.186 X-Spam-Level: X-Spam-Status: No, score=-106.186 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGE+GQIvyMxd; Mon, 13 Jun 2011 20:50:49 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [64.170.98.47]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7E421F8539; Mon, 13 Jun 2011 20:50:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 97FE698C50D; Mon, 13 Jun 2011 20:50:36 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110614035036.97FE698C50D@rfc-editor.org> Date: Mon, 13 Jun 2011 20:50:36 -0700 (PDT) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6264 on An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 03:50:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6264 Title: An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition Author: S. Jiang, D. Guo, B. Carpenter Status: Informational Stream: IETF Date: June 2011 Mailbox: jiangsheng@huawei.com, guoseu@huawei.com, brian.e.carpenter@gmail.com Pages: 13 Characters: 31881 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-incremental-cgn-03.txt URL: http://www.rfc-editor.org/rfc/rfc6264.txt 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 reusable during different transition phases, avoiding multiple upgrades. This enables IPv6 migration to be incrementally achieved according to real user requirements. 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 swmike@swm.pp.se Mon Jun 13 21:20:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358C31F0C3E; Mon, 13 Jun 2011 21:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAeyN+-FLWml; Mon, 13 Jun 2011 21:20:02 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id AC2B11F0C35; Mon, 13 Jun 2011 21:20:01 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6089E9C; Tue, 14 Jun 2011 06:19:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5B2F69A; Tue, 14 Jun 2011 06:19:58 +0200 (CEST) Date: Tue, 14 Jun 2011 06:19:58 +0200 (CEST) From: Mikael Abrahamsson To: Ted Lemon In-Reply-To: <701DCBC2-E1B6-420A-B258-504589335A20@nominum.com> Message-ID: References: <4DF291D0.7080707@gont.com.ar> <4DF69180.6050902@inex.ie> <701DCBC2-E1B6-420A-B258-504589335A20@nominum.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 04:20:07 -0000 On Mon, 13 Jun 2011, Ted Lemon wrote: > On Jun 13, 2011, at 3:38 PM, Nick Hilliard wrote: >> dhcpv6 suffers from exactly the same problem. Are there plans to introduce dhcpv6-guard? > > Nobody's proposed it. I'd be surprised if implementations of this wouldn't also have some kind of idea or concept of "client ports" and "server ports"? -- Mikael Abrahamsson email: swmike@swm.pp.se From bob.hinden@gmail.com Mon Jun 13 21:51:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B9B11E8132; Mon, 13 Jun 2011 21:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_BEZEQINT_B=0.763, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pA8WQ1nMPHJp; Mon, 13 Jun 2011 21:51:53 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id D38A411E80BE; Mon, 13 Jun 2011 21:51:52 -0700 (PDT) Received: by wwk4 with SMTP id 4so3173310wwk.1 for ; Mon, 13 Jun 2011 21:51:39 -0700 (PDT) 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=6AThwAjNBVwPIKrUgpuFEpb/oXzGgDCcnmzweIpCl+Y=; b=NV3Qq92MVq0LJRz9+0UOFrFG20XgQ1OlawVA9896fKvBJ+SGYB1MPl6A9UZpQz+bhf GYbHxuoQe1pmqKTfhfA1Z4VTrXsKO8UKpgUWkhweRYrkNSEMJTUHIefMK5Abbvyh9S6u CziJVwgJMkI+N1l8fWDTRmbG/zWlu/5JzJQwc= 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=Kxho02N5kcfl28ZqEuMuPQJMjWGd5N7avksGSVy2VcIOyY0xTg7CFcujz7xHAVW67t j1Q5pqte8yl0jfy59w/po6+CXHVLLKatULLejgrzARwH9zXCDRQ0h/bAdHbw0bGiPkpo RWCteZJatH0jaxGP1FVvonGDmidwVujGB3TSc= Received: by 10.227.196.193 with SMTP id eh1mr5937739wbb.12.1308027098894; Mon, 13 Jun 2011 21:51:38 -0700 (PDT) Received: from [192.168.4.127] (bzq-218-39-93.cablep.bezeqint.net [81.218.39.93]) by mx.google.com with ESMTPS id fl19sm4717598wbb.49.2011.06.13.21.51.37 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Jun 2011 21:51:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Bob Hinden In-Reply-To: Date: Tue, 14 Jun 2011 07:51:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <22C01597-E89D-4200-8251-2F3979ABB0B6@gmail.com> References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> To: Russ Housley X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org, v6ops@ietf.org, "saag@ietf.org" , Stephen Farrell Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 04:51:54 -0000 Russ, On Jun 14, 2011, at 2:57 AM, Russ Housley wrote: > Stephen: >=20 > Comments below. >=20 > Russ >=20 >=20 >> From: IETF Security Area >> To: Study Group 17, Questions 2 and 3 >> Title: Work on Security of IPv6 >>=20 >> FOR ACTION >>=20 >> The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on = IPv6 >> security issues". As the world transitions to IPv6, new = opportunities >> and challenges and challenges arise. SG17's new focus on deployment = and >=20 > s/and challenges and challenges/and challenges/ > s/new// >=20 >> implementation considerations reflects this reality. We would like = to >> bring to your attention the following work which we believe may prove = a >> useful basis for both X.ipv6-secguide and X.mgv6: >>=20 >> * RFC 4294 =96 "IPv6 Node Requirements" (N.B., this work is = currently >> under revision) >=20 > Why not just reference the bis document? >=20 >> * draft-ietf-6man-node-req-bis (work in progress) =96 "IPv6 Node >> Requirements RFC 4294-bis" The draft could also say that the working group has reached consensus = and has submitted it to the IESG for publication on 25 May 2011. Bob >> * RFC 4864 =96 "Local Network Protection for IPv6" >> * RFC 6092 =96 "Recommended Simple Security Capabilities in = Customer >> Premise Equipment (CPE) for Providing Residential IPv6 Internet >> Service" >> * RFC 6105 =96 "IPv6 Router Advertisement Guard" >> * RFC 6106 =96 "IPv6 Router Advertisement Options for DNS >> Configuration", =A77 in particular. >>=20 >> As you are aware, every RFC contains a Security Considerations = section. >> In developing either a implementation or deployment guide, = contributors >> are strongly encouraged to review the RFCs and Internet-Drafts that >> support any underlying function. >>=20 >> In addition, we bring to your attention the following IETF Working >> Groups that are working on security-related work of IPv6: >>=20 >> Working Group Purpose Mailing list address >> Name >>=20 >> 6man IPv6 Maintenance ipv6@ietf.org >> savi Source Address Validation savi@ietf.org >> Improvements >> dhc Dynamic Host Configuration dhcwg@ietf.org >> v6ops IPv6 Operations v6ops@ietf.org >> opsec Operational Security opsec@ietf.org >> Capabilities for an IP >> Network >>=20 >> In addition to the above working groups, the Security Area of the = IETF >> maintains a mailing list for general discussion, saag@ietf.org. We >> encourage and invite open and informal discussion in these or other >> relevant IETF fora on this very important topic. As with all IETF >> working groups, any and all interested parties can choose to directly >> contribute via the mailing lists above. >>=20 >> As in other areas, the Security Area of the IETF invites SG17 to = bring >> any new-found concerns about IETF protocols to our attention so that = as >> and when we revise our documents we can make appropriate amendments = to >> IETF protocols. In particular, as this planned work matures, we would >> welcome hearing about it in more detail, perhaps via an invited >> presentation at a saag meeting or via review of draft documents as = may >> be appropriate. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From stephen.farrell@cs.tcd.ie Tue Jun 14 00:20:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D899611E8111; Tue, 14 Jun 2011 00:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.423 X-Spam-Level: X-Spam-Status: No, score=-105.423 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFC4dtBetRgx; Tue, 14 Jun 2011 00:20:03 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 39E2011E8070; Tue, 14 Jun 2011 00:20:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5114715356B; Tue, 14 Jun 2011 08:19:56 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1308035995; bh=2883g 9CmH7gUGjXVhpis5QtP7w9of6b9492MzLkdFx8=; b=GYUhs7mKtMTfTjB89UNZG IjQnCGr3w5fi3aNWPWmnMSIRIZMMbZpuLBvGaUxsC/p+XQGGWzlxD5wzBilYfUgW GTx9N/O1JQAVcrHOz6jOCMZa3xrECCkIpgj1UxMPkyhn98LS/myOwYMXj5Ot1FEr 5qltKMkd3hkLfxjsB59SaEY7huvTJa1CHd1KLR2zPu8QyTpYT1D2inmDIodxHZ8Z 99I/dM5xcOiMMOENkiW4OjHlmrN0PgRy3htmvq73O3nAU7kfM5sdieQDZOjZGr6v JYYb+qpfVSu9XoyryHhWt2xXXLgjKhCtMnGkQcVxS/uG8RcmbXbyVilKXwgNCNQA A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Pjz+6LKmtmjs; Tue, 14 Jun 2011 08:19:55 +0100 (IST) Received: from [10.87.48.6] (unknown [86.42.18.245]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C321A15356A; Tue, 14 Jun 2011 08:19:54 +0100 (IST) References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <22C01597-E89D-4200-8251-2F3979ABB0B6@gmail.com> In-Reply-To: <22C01597-E89D-4200-8251-2F3979ABB0B6@gmail.com> Mime-Version: 1.0 (iPhone Mail 8H7) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (8H7) From: Stephen Farrell Date: Tue, 14 Jun 2011 08:19:52 +0100 To: Bob Hinden Cc: "v6ops@ietf.org" , Russ Housley , "saag@ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 07:20:05 -0000 On 14 Jun 2011, at 05:51, Bob Hinden wrote: > Russ, >=20 > On Jun 14, 2011, at 2:57 AM, Russ Housley wrote: >=20 >> Stephen: >>=20 >> Comments below. >>=20 >> Russ >>=20 >>=20 >>> From: IETF Security Area >>> To: Study Group 17, Questions 2 and 3 >>> Title: Work on Security of IPv6 >>>=20 >>> FOR ACTION >>>=20 >>> The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 >>> security issues". As the world transitions to IPv6, new opportunities >>> and challenges and challenges arise. SG17's new focus on deployment and= >>=20 >> s/and challenges and challenges/and challenges/ >> s/new// >>=20 >>> implementation considerations reflects this reality. We would like to >>> bring to your attention the following work which we believe may prove a >>> useful basis for both X.ipv6-secguide and X.mgv6: >>>=20 >>> * RFC 4294 =E2=80=93 "IPv6 Node Requirements" (N.B., this work is curre= ntly >>> under revision) >>=20 >> Why not just reference the bis document? >=20 >>=20 >>> * draft-ietf-6man-node-req-bis (work in progress) =E2=80=93 "IPv6 Node >>> Requirements RFC 4294-bis" >=20 >=20 > The draft could also say that the working group has reached consensus and h= as submitted it to the IESG for publication on 25 May 2011. Will do, S >=20 > Bob >=20 >=20 >>> * RFC 4864 =E2=80=93 "Local Network Protection for IPv6" >>> * RFC 6092 =E2=80=93 "Recommended Simple Security Capabilities in Custo= mer >>> Premise Equipment (CPE) for Providing Residential IPv6 Internet >>> Service" >>> * RFC 6105 =E2=80=93 "IPv6 Router Advertisement Guard" >>> * RFC 6106 =E2=80=93 "IPv6 Router Advertisement Options for DNS >>> Configuration", =C2=A77 in particular. >>>=20 >>> As you are aware, every RFC contains a Security Considerations section. >>> In developing either a implementation or deployment guide, contributors >>> are strongly encouraged to review the RFCs and Internet-Drafts that >>> support any underlying function. >>>=20 >>> In addition, we bring to your attention the following IETF Working >>> Groups that are working on security-related work of IPv6: >>>=20 >>> Working Group Purpose Mailing list address >>> Name >>>=20 >>> 6man IPv6 Maintenance ipv6@ietf.org >>> savi Source Address Validation savi@ietf.org >>> Improvements >>> dhc Dynamic Host Configuration dhcwg@ietf.org >>> v6ops IPv6 Operations v6ops@ietf.org >>> opsec Operational Security opsec@ietf.org >>> Capabilities for an IP >>> Network >>>=20 >>> In addition to the above working groups, the Security Area of the IETF >>> maintains a mailing list for general discussion, saag@ietf.org. We >>> encourage and invite open and informal discussion in these or other >>> relevant IETF fora on this very important topic. As with all IETF >>> working groups, any and all interested parties can choose to directly >>> contribute via the mailing lists above. >>>=20 >>> As in other areas, the Security Area of the IETF invites SG17 to bring >>> any new-found concerns about IETF protocols to our attention so that as >>> and when we revise our documents we can make appropriate amendments to >>> IETF protocols. In particular, as this planned work matures, we would >>> welcome hearing about it in more detail, perhaps via an invited >>> presentation at a saag meeting or via review of draft documents as may >>> be appropriate. >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From tjc@ecs.soton.ac.uk Tue Jun 14 00:25:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61B611E8088; Tue, 14 Jun 2011 00:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75e3ObBSLDbD; Tue, 14 Jun 2011 00:25:07 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 7494711E8087; Tue, 14 Jun 2011 00:25:06 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5E7P13m019120; Tue, 14 Jun 2011 08:25:01 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p5E7P13m019120 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1308036301; bh=rBVPClm7597qoSZdBvmzEvZaziE=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=MZY+HJ1oabiVIjGx4hhw/N4mK9/xMoNhjxeuSYSMZCI3+xDWkZDgmkccFvljLhktt n+O+kIH+o2C6ncNGUaTprt5umbpyNDhGt4KJpQe3XeoGLFNbbo/Qk0YcoB/uYn0lmF iHJ/nNYpCpg4IU4cC5naEW0leKYG9DauUol3dNM0= 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 n5D8P10521301716oi ret-id none; Tue, 14 Jun 2011 08:25:01 +0100 Received: from [192.168.1.14] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5E7NbqT021992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Jun 2011 08:23:37 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Tim Chown In-Reply-To: <4DF6B804.4040703@gont.com.ar> Date: Tue, 14 Jun 2011 08:23:37 +0100 Content-Transfer-Encoding: 7bit Message-ID: References: <4DF291D0.7080707@gont.com.ar> <4DF69180.6050902@inex.ie> <4DF6B804.4040703@gont.com.ar> To: IPv6 Operations , 6man X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n5D8P1052130171600; tid=n5D8P10521301716oi; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p5E7P13m019120 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 07:25:08 -0000 On 14 Jun 2011, at 02:23, Fernando Gont wrote: >> Are there plans to introduce dhcpv6-guard? > > This is something that vendors should answer. As long as there are > implementations that may try DHCPv6 even if no RA is received, DHCPv6 > should be implemented/deployed along RA-Guard, or else attackers will > switch to teh DHCPv6 vector, and RA-Guard will be circumvented this way. I am aware of it being on the roadmap for one significant router vendor. But that model is familiar from IPv4. Tim From nick@inex.ie Tue Jun 14 03:00:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5588121F85CC; Tue, 14 Jun 2011 03:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFnPb+cqO35Y; Tue, 14 Jun 2011 03:00:36 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [46.182.8.5]) by ietfa.amsl.com (Postfix) with ESMTP id C10AB21F85C7; Tue, 14 Jun 2011 03:00:35 -0700 (PDT) X-Envelope-To: saag@ietf.org Received: from cupcake.internal.acquirer.com (mail.acquirer.com [87.198.142.10] (may be forged)) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id p5EA0OHg041950 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Jun 2011 11:00:25 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4DF73138.6010009@inex.ie> Date: Tue, 14 Jun 2011 11:00:24 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110528 Thunderbird/5.0b1 MIME-Version: 1.0 To: Stephen Farrell References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> In-Reply-To: <4DF69899.2050606@cs.tcd.ie> X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 10:00:37 -0000 On 14/06/2011 00:09, Stephen Farrell wrote: > * RFC 6105 – "IPv6 Router Advertisement Guard" > * RFC 6106 – "IPv6 Router Advertisement Options for DNS > Configuration", §7 in particular. maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic focused document, but gives specific advice on a specific issue which is relevant to ipv6 lan deployments. Nick From stephen.farrell@cs.tcd.ie Tue Jun 14 04:07:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971D311E8097; Tue, 14 Jun 2011 04:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.045 X-Spam-Level: X-Spam-Status: No, score=-106.045 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lRRCT9lnv74; Tue, 14 Jun 2011 04:07:40 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id C9C7F11E8071; Tue, 14 Jun 2011 04:07:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B1308171C03; Tue, 14 Jun 2011 12:07:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308049638; bh=BR372cB96WaTSt J2eDtWqWz7b9GALC6jcCwc47ovgKg=; b=CIliRfxuv9AVgQ458vvKDKCI0SWR49 j1S6c21C/Z3gmv+Hg/SV4ToP93TDUARCbT3aj/TPilMLPES59RW6nJSHojfH0yqp DzTvfZ6aWY5gVHoLcYFfveHBOMPTv45y94UWlMINuh67BIb5go/UHFtWBQRCSmYB m+njLBm/Fp1IyS/1oGLL9MrDuMXYrk2idNFbP4S0m/6WWUi5qUjyA7Pj0EMjAfxG WKt9wkMxsno7B6UuQswtMkKUV9x8ol2Dw9ZDbCVoX8xqYs6hUjaDSK4nBvWaCvPU zh7vIcbki6nCFs4pznmo9AWk4RHM6ypHLJANq5jQm/IkQVZVYQRmwFdQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id bB+PEJkkE4sb; Tue, 14 Jun 2011 12:07:18 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 63DD7171C01; Tue, 14 Jun 2011 12:07:17 +0100 (IST) Message-ID: <4DF740E5.4030309@cs.tcd.ie> Date: Tue, 14 Jun 2011 12:07:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nick Hilliard References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> In-Reply-To: <4DF73138.6010009@inex.ie> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 11:07:41 -0000 Thanks Nick, I'll add that unless someone tells me its a bad plan. Its a fairly fresh I-D, but I guess it looks pretty relevant all right. S. On 14/06/11 11:00, Nick Hilliard wrote: > On 14/06/2011 00:09, Stephen Farrell wrote: >> * RFC 6105 – "IPv6 Router Advertisement Guard" >> * RFC 6106 – "IPv6 Router Advertisement Options for DNS >> Configuration", §7 in particular. > > maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic > focused document, but gives specific advice on a specific issue which is > relevant to ipv6 lan deployments. > > Nick > From nick@inex.ie Tue Jun 14 05:25:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E3511E80B5; Tue, 14 Jun 2011 05:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVSJFEdsL7KY; Tue, 14 Jun 2011 05:25:28 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [46.182.8.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6083C11E80A8; Tue, 14 Jun 2011 05:25:27 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from cupcake.internal.acquirer.com (mail.acquirer.com [87.198.142.10] (may be forged)) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id p5ECPDxr043934 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Jun 2011 13:25:14 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4DF75328.6060109@inex.ie> Date: Tue, 14 Jun 2011 13:25:12 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110528 Thunderbird/5.0b1 MIME-Version: 1.0 To: Fernando Gont References: <4DF291D0.7080707@gont.com.ar> <4DF69180.6050902@inex.ie> <4DF6B804.4040703@gont.com.ar> In-Reply-To: <4DF6B804.4040703@gont.com.ar> X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 12:25:29 -0000 On 14/06/2011 02:23, Fernando Gont wrote: > This is something that vendors should answer. As long as there are > implementations that may try DHCPv6 even if no RA is received, DHCPv6 > should be implemented/deployed along RA-Guard, or else attackers will > switch to teh DHCPv6 vector, and RA-Guard will be circumvented this way. probably vendors aren't going to do much about dhcp6-guard unless there is a standard to work towards. I'd offer to help out, but my dhcpv6-fu is not really up to it. Nick From Ted.Lemon@nominum.com Tue Jun 14 07:03:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485439E8005; Tue, 14 Jun 2011 07:03:53 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygEgEoEEbwUG; Tue, 14 Jun 2011 07:03:52 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5429E8004; Tue, 14 Jun 2011 07:03:52 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTfdqRwbnD7ctk63xaJZ4HxIMzpqyOkFJ@postini.com; Tue, 14 Jun 2011 07:03:52 PDT 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 5E26DF8063; Tue, 14 Jun 2011 07:03:51 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 506B419005D; Tue, 14 Jun 2011 07:03:51 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([169.254.1.65]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0289.001; Tue, 14 Jun 2011 07:03:51 -0700 From: Ted Lemon To: Nick Hilliard Thread-Topic: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) Thread-Index: AQHMKhrK4nfvsQF/6k2M3T/2n95cnZS8hGgAgAC48QD//6Y4Zw== Date: Tue, 14 Jun 2011 14:03:50 +0000 Message-ID: <7D140A8C-6EB2-4EC8-8852-8BEBF9C311F9@nominum.com> References: <4DF291D0.7080707@gont.com.ar> <4DF69180.6050902@inex.ie> <4DF6B804.4040703@gont.com.ar>,<4DF75328.6060109@inex.ie> In-Reply-To: <4DF75328.6060109@inex.ie> 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 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 14:03:53 -0000 On Jun 14, 2011, at 5:26 AM, "Nick Hilliard" wrote: > probably vendors aren't going to do much about dhcp6-guard unless there i= s a standard to work towards. I'd offer to help out, but my dhcpv6-fu is Can you come to the dhcwg meeting and talk with us about the problem?= From suresh.krishnan@ericsson.com Tue Jun 14 08:34:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2F311E813E; Tue, 14 Jun 2011 08:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.21 X-Spam-Level: X-Spam-Status: No, score=-106.21 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egDgaaoeXu04; Tue, 14 Jun 2011 08:34:23 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 82CAB11E80B0; Tue, 14 Jun 2011 08:34:21 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p5EFYDKn017018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jun 2011 10:34:14 -0500 Received: from [142.133.10.107] (147.117.20.214) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.3.137.0; Tue, 14 Jun 2011 11:34:13 -0400 Message-ID: <4DF77E98.8030300@ericsson.com> Date: Tue, 14 Jun 2011 11:30:32 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Stephen Farrell References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> In-Reply-To: <4DF69899.2050606@cs.tcd.ie> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , "ipv6@ietf.org" , "saag@ietf.org" Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 15:34:25 -0000 Hi Stephen, Please consider adding the following RFCs to the list. RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats RFC4890 Recommendations for Filtering ICMPv6 Messages in Firewalls RFC4942 IPv6 Transition/Co-existence Security Considerations RFC5157 IPv6 Implications for Network Scanning Thanks Suresh On 11-06-13 07:09 PM, Stephen Farrell wrote: > All, > > Thanks for the feedback on this liaison. Eliot (mostly) > and I (a bit) have tried to capture all that in the > text below. Please send any comments on that (with > specific alternative text) in the next week and then > we'll shoot it on to them. > > RFC 3514 does have some words about IPv6 - should I > add that as a reference? :-) > > Thanks, > Stephen. > > From: IETF Security Area > To: Study Group 17, Questions 2 and 3 > Title: Work on Security of IPv6 > > FOR ACTION > > The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 > security issues". As the world transitions to IPv6, new opportunities > and challenges and challenges arise. SG17's new focus on deployment and > implementation considerations reflects this reality. We would like to > bring to your attention the following work which we believe may prove a > useful basis for both X.ipv6-secguide and X.mgv6: > > * RFC 4294 – "IPv6 Node Requirements" (N.B., this work is currently > under revision) > * draft-ietf-6man-node-req-bis (work in progress) – "IPv6 Node > Requirements RFC 4294-bis" > * RFC 4864 – "Local Network Protection for IPv6" > * RFC 6092 – "Recommended Simple Security Capabilities in Customer > Premise Equipment (CPE) for Providing Residential IPv6 Internet > Service" > * RFC 6105 – "IPv6 Router Advertisement Guard" > * RFC 6106 – "IPv6 Router Advertisement Options for DNS > Configuration", §7 in particular. > > As you are aware, every RFC contains a Security Considerations section. > In developing either a implementation or deployment guide, contributors > are strongly encouraged to review the RFCs and Internet-Drafts that > support any underlying function. > > In addition, we bring to your attention the following IETF Working > Groups that are working on security-related work of IPv6: > > Working Group Purpose Mailing list address > Name > > 6man IPv6 Maintenance ipv6@ietf.org > savi Source Address Validation savi@ietf.org > Improvements > dhc Dynamic Host Configuration dhcwg@ietf.org > v6ops IPv6 Operations v6ops@ietf.org > opsec Operational Security opsec@ietf.org > Capabilities for an IP > Network > > In addition to the above working groups, the Security Area of the IETF > maintains a mailing list for general discussion, saag@ietf.org. We > encourage and invite open and informal discussion in these or other > relevant IETF fora on this very important topic. As with all IETF > working groups, any and all interested parties can choose to directly > contribute via the mailing lists above. > > As in other areas, the Security Area of the IETF invites SG17 to bring > any new-found concerns about IETF protocols to our attention so that as > and when we revise our documents we can make appropriate amendments to > IETF protocols. In particular, as this planned work matures, we would > welcome hearing about it in more detail, perhaps via an invited > presentation at a saag meeting or via review of draft documents as may > be appropriate. > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jhw@apple.com Tue Jun 14 10:30:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584AB11E817C; Tue, 14 Jun 2011 10:30:27 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pa0TfJFFcrL; Tue, 14 Jun 2011 10:30:26 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9DB11E817F; Tue, 14 Jun 2011 10:30:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LMS002W8J904T00@mail-out.apple.com>; Tue, 14 Jun 2011 10:30:13 -0700 (PDT) X-AuditID: 11807134-b7c00ae0000074fb-3a-4df79aa5a032 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 55.C1.29947.5AA97FD4; Tue, 14 Jun 2011 10:30:13 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LMS00EWKJADCJ30@cardamom.apple.com>; Tue, 14 Jun 2011 10:30:13 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 14 Jun 2011 10:30:12 -0700 Message-id: References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1237.1) X-Brightmail-Tracker: AAAAAA== Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 17:30:27 -0000 On Jun 10, 2011, at 09:38 , Lorenzo Colitti wrote: > > I fundamentally disagree. I really don't think that 6to4 is used by "lots" of people for applications that wouldn't just use (more reliable) IPv4 if 6to4 wasn't there. The same is often said about IPv6 in general. That's not meant to be snarky quip. When you limit the population under observation to just current IPv6 users and leave out the vast teeming masses of people who are routed IPv4-only, I suspect the data will show that a significant fraction of people are still using 6to4 as a general network-layer NAT-avoidance mechanism because it continues to work for them, setting up a manual tunnel-broker account takes an order of magnitude more effort, and who has time? Very few of the people using 6to4 in this way will show up in Google's user behavior analysis, of course, because Google doesn't run its own 6to4 return-path relay as I-D.ietf-v6ops-6to4-advisory recommends. The way to find these people is to crawl the BitTorrent networks. What's that old maxim? "You can't test what you don't measure." Do you measure the BitTorrent networks? -- james woodyatt member of technical staff, core os networking From lorenzo@google.com Tue Jun 14 11:00:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB559E800A for ; Tue, 14 Jun 2011 11:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0c-f47Y4byh for ; Tue, 14 Jun 2011 11:00:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 069D821F8480 for ; Tue, 14 Jun 2011 11:00:14 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p5EI0DFJ005694 for ; Tue, 14 Jun 2011 11:00:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308074414; bh=624XQbmp+rGZhC7kAJ3OYO0Rhsg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=fGM2Tj/vKVK80lsIMsfhZOUBgPWlvnG6RhVgVBKj9zyBRadw4dJzrY1QODT5YjILT guKWEPVJ9yISt/uk2R7rw== Received: from ywl41 (ywl41.prod.google.com [10.192.12.41]) by wpaz9.hot.corp.google.com with ESMTP id p5EHtohZ016524 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 14 Jun 2011 11:00:07 -0700 Received: by ywl41 with SMTP id 41so3512239ywl.4 for ; Tue, 14 Jun 2011 11:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Oy88dhrYWuKFP8esGkFa0M0fc5jvOAhql2POw8H44D4=; b=bF5UvpIDgKzeHNjItkfzNvZJtkOCtBR6yObmUrnXivhJOqXszhEDUz/C0kJkji4b1w 0gF/2pdQI0LAYD8fvaxg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=to4D+gc0TIhXxi3alDIWwuTy1dY4F4O7w/EHt1rxWMNXgzT6Fc+qYD7dAQBbHzxyT2 rM8cGI+D6AK3AW9iqBxw== Received: by 10.150.195.18 with SMTP id s18mr7944004ybf.207.1308074407090; Tue, 14 Jun 2011 11:00:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.147.16 with HTTP; Tue, 14 Jun 2011 10:59:47 -0700 (PDT) In-Reply-To: References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> From: Lorenzo Colitti Date: Tue, 14 Jun 2011 10:59:47 -0700 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=000e0cd4d83c5fda2704a5afce0e X-System-Of-Record: true Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 18:00:16 -0000 --000e0cd4d83c5fda2704a5afce0e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 14, 2011 at 10:30 AM, james woodyatt wrote: > > Very few of the people using 6to4 in this way will show up in Google's user > behavior analysis, of course, because Google doesn't run its own 6to4 > return-path relay as I-D.ietf-v6ops-6to4-advisory recommends. > We would not see these users even if we operated reverse path relays as recommended in the draft - from the point of view of the server, in both cases it's just a TCP connection to a 2002::/16 address, regardless of whether the relay is inside the Google network or outside it. Those users would become visible if we added AAAA records with 6to4 addresses, but that's a bad plan because it would likely lead to the double-digit connection failure rates that Geoff observes. It would also become visible if Google operated an open anycast relay, which we do not plan to do. > The way to find these people is to crawl the BitTorrent networks. What's > that old maxim? "You can't test what you don't measure." Do you measure > the BitTorrent networks? No, we don't. The measurements we conduct have the purpose of determining the impact of adding AAAA records to web sites, so we don't measure the population of users that has 6to4 but does not use it to make HTTP connections to dual-stack websites. We do measure the impact of 6to4 on the reliability of websites indirectly, e.g., by observing the difference between OSes that prefer IPv4 over 6to4 and OSes that don't. Also, is there a way we can put this debate to rest using real data? What if we asked someone like Hurricane Electric how much traffic on their network is native IPv6 vs. 6to4? That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? --000e0cd4d83c5fda2704a5afce0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 14, 2011 at 10:30 AM, james woodyatt= <jhw@apple.com&g= t; wrote:=A0
Very few of the people using 6to4 in this way will show u= p in Google's user behavior analysis, of course, because Google doesn&#= 39;t run its own 6to4 return-path relay as I-D.ietf-v6ops-6to4-advisory rec= ommends.

We would not see these users even if we op= erated reverse path relays as recommended in the draft - from the point of = view of the server, in both cases it's just a TCP connection to a 2002:= :/16 address, regardless of whether the relay is inside the Google network = or outside it.

Those users would become visible if we added AAAA = records with 6to4 addresses, but that's a bad plan because it would lik= ely lead to the double-digit connection failure rates that Geoff observes. = It would also become visible if Google operated=A0an open anycast relay, wh= ich we do not plan to do.
=A0
The way to find these p= eople is to crawl the BitTorrent networks. =A0What's that old maxim? = =A0"You can't test what you don't measure." =A0Do you mea= sure the BitTorrent networks?

No, we don't. The measurements we conduct have the = purpose of determining the impact of adding AAAA records to web sites, so w= e don't measure the population of users that has 6to4 but does not use = it to make HTTP connections to dual-stack websites.=A0We do measure the imp= act of 6to4 on the reliability of websites indirectly, e.g., by observing t= he difference between OSes that prefer IPv4 over 6to4 and OSes that don'= ;t.

Also, is there a way we can put this debate to rest using= real data? What if we asked someone like Hurricane Electric how much traff= ic on their network is native IPv6 vs. 6to4?

That said, I would argue that most or all 6to4 traffic = could just as well use IPv4, since both parties to the communication obviou= sly have access to a public IPv4 address. What is the advantage of using 6t= o4 over IPv4 that makes it worth suffering an 80% failure rate?
--000e0cd4d83c5fda2704a5afce0e-- From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Jun 14 15:41:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5B91F0C8A; Tue, 14 Jun 2011 15:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwEIL-MldIna; Tue, 14 Jun 2011 15:40:59 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2281F0C88; Tue, 14 Jun 2011 15:40:59 -0700 (PDT) Received: from 219-90-147-167.ip.adam.com.au ([219.90.147.167] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QWcI1-0005wD-7u; Wed, 15 Jun 2011 08:10:53 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 63D963B33E; Wed, 15 Jun 2011 08:10:51 +0930 (CST) Date: Wed, 15 Jun 2011 08:10:50 +0930 From: Mark Smith To: Lorenzo Colitti Message-ID: <20110615081050.70c9112a@opy.nosense.org> In-Reply-To: References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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 WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 22:41:00 -0000 On Tue, 14 Jun 2011 10:59:47 -0700 Lorenzo Colitti wrote: > On Tue, Jun 14, 2011 at 10:30 AM, james woodyatt wrote: > > > > Very few of the people using 6to4 in this way will show up in Google's user > > behavior analysis, of course, because Google doesn't run its own 6to4 > > return-path relay as I-D.ietf-v6ops-6to4-advisory recommends. > > > > We would not see these users even if we operated reverse path relays as > recommended in the draft - from the point of view of the server, in both > cases it's just a TCP connection to a 2002::/16 address, regardless of > whether the relay is inside the Google network or outside it. > > Those users would become visible if we added AAAA records with 6to4 > addresses, but that's a bad plan because it would likely lead to the > double-digit connection failure rates that Geoff observes. It would also > become visible if Google operated an open anycast relay, which we do not > plan to do. > I don't know if it is intentional, however if I use Google's public 8.8.8.8 and 8.8.4.4 resolvers, and prefer 6to4 over native IPv4 (via /etc/gai.conf under Linux/glibc), it seems that the video content of all youtube videos is now being delivered over IPv6. The same thing happens if I use my ISP's resolvers - I know they're doing IPv6 work behind the scenes, however I don't know but dont think their resolvers are Google whitelisted. That suggests that if there are hosts out there that blindly prefer tunnelled IPv6 over native IPv4, and have 6to4 available, there is a likelyhood that more people are using 6to4 now than there was before World IPv6 day. I'm having no performance problems at all with any videos I select, including 1080P ones. > > > The way to find these people is to crawl the BitTorrent networks. What's > > that old maxim? "You can't test what you don't measure." Do you measure > > the BitTorrent networks? > > > No, we don't. The measurements we conduct have the purpose of determining > the impact of adding AAAA records to web sites, so we don't measure the > population of users that has 6to4 but does not use it to make HTTP > connections to dual-stack websites. We do measure the impact of 6to4 on the > reliability of websites indirectly, e.g., by observing the difference > between OSes that prefer IPv4 over 6to4 and OSes that don't. > > Also, is there a way we can put this debate to rest using real data? What if > we asked someone like Hurricane Electric how much traffic on their network > is native IPv6 vs. 6to4? > > That said, I would argue that most or all 6to4 traffic could just as well > use IPv4, since both parties to the communication obviously have access to a > public IPv4 address. What is the advantage of using 6to4 over IPv4 that > makes it worth suffering an 80% failure rate? I'm having and have been having 100% success rate (or near enough to it that I can remember) using 6to4 for a number of years, including with an IPv6 MTU of as large as my PPPoE connection will support i.e. my 6to4 tunnel has an IPv6 MTU of 1472. Since noticing that youtube videos are coming over IPv6, I've paid a bit more attention to the "quality of experience" I've had, and have not found any reasons to change my preference back to native IPv4 instead of 6to4. From ek@google.com Tue Jun 14 16:05:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BCD11E807D for ; Tue, 14 Jun 2011 16:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEY4LpXhub3T for ; Tue, 14 Jun 2011 16:05:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA7811E8078 for ; Tue, 14 Jun 2011 16:05:52 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p5EN5eNB024553 for ; Tue, 14 Jun 2011 16:05:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308092741; bh=Zci261TLzJzDk7BA7J2e0ff/xlw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=UwXKVKh64b/OacXmzL0H0frNgNcuHbIle3hzcduSVrY15TlHYokfpsCPIUq5xoldY awnXtW3nz09KuR+ESg1lw== Received: from pvc12 (pvc12.prod.google.com [10.241.209.140]) by hpaq11.eem.corp.google.com with ESMTP id p5EN58Gc027992 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 14 Jun 2011 16:05:34 -0700 Received: by pvc12 with SMTP id 12so3610543pvc.14 for ; Tue, 14 Jun 2011 16:05:34 -0700 (PDT) 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=P95cOrBJVFmX46mwyEqA8GSsbZDKIKVjch5mFVeRpuI=; b=wJlFiq3UUndKi/5TqgBKDouXr2YIg9WjN/kQVFEaiHCpQ2vtx9tHFpENFg1E2ctGDQ 3zqaoGiUCIvYrJuPv4gA== 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=arPlbChVFYAAUNfWW/qNk1Sysci4MfVMc07aQJROycSZVDPbna2ZTNKKGLxzxCfHXR 0gc19eDg1vcze6oztIWA== MIME-Version: 1.0 Received: by 10.142.142.13 with SMTP id p13mr1324744wfd.324.1308092733863; Tue, 14 Jun 2011 16:05:33 -0700 (PDT) Received: by 10.143.37.8 with HTTP; Tue, 14 Jun 2011 16:05:33 -0700 (PDT) In-Reply-To: <20110615081050.70c9112a@opy.nosense.org> References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> <20110615081050.70c9112a@opy.nosense.org> Date: Tue, 14 Jun 2011 16:05:33 -0700 Message-ID: From: Erik Kline To: Mark Smith Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 23:05:52 -0000 The youtube folks made the decision to leave the video-serving hostnames available in blacklist-mode, meaning only very broken networks won't get AAAAs. This is being watched, and could easily change back. The exact policy for blacklisting has yet to be fully formalized. But re: 6to4 in this case, it still gains you nothing you didn't already have while risking randomly crappy performance. From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Jun 14 16:30:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A558311E80DF; Tue, 14 Jun 2011 16:30:07 -0700 (PDT) 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.100, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGdjY5zez5wf; Tue, 14 Jun 2011 16:30:05 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id B015111E80A8; Tue, 14 Jun 2011 16:30:05 -0700 (PDT) Received: from 219-90-147-167.ip.adam.com.au ([219.90.147.167] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QWd3b-0008Ju-QV; Wed, 15 Jun 2011 09:00:03 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 9DE343B33E; Wed, 15 Jun 2011 09:00:02 +0930 (CST) Date: Wed, 15 Jun 2011 09:00:02 +0930 From: Mark Smith To: Erik Kline Message-ID: <20110615090002.066f3219@opy.nosense.org> In-Reply-To: References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> <20110615081050.70c9112a@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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 WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 23:30:08 -0000 On Tue, 14 Jun 2011 16:05:33 -0700 Erik Kline wrote: > The youtube folks made the decision to leave the video-serving > hostnames available in blacklist-mode, meaning only very broken > networks won't get AAAAs. > > This is being watched, and could easily change back. The exact policy > for blacklisting has yet to be fully formalized. > > But re: 6to4 in this case, it still gains you nothing you didn't > already have while risking randomly crappy performance. A less used content cache could give me better performance. Not that it has happened recently, however in the past there have been IPv4 delivered performance issues with youtube here in .au. That's the reason I've paid a bit more attention to the quality of IPv6 delivery and tried 1080P videos when they've been available. Regards, Mark. From touch@isi.edu Tue Jun 14 17:17:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCF81F0C5C; Tue, 14 Jun 2011 17:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.38 X-Spam-Level: X-Spam-Status: No, score=-101.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drapnSrBNONL; Tue, 14 Jun 2011 17:17:48 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id F167E1F0C5B; Tue, 14 Jun 2011 17:17:47 -0700 (PDT) Received: from [192.168.121.117] ([221.148.74.64]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p5F0HIuB019915 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 14 Jun 2011 17:17:22 -0700 (PDT) Message-ID: <4DF7FA0D.6040201@isi.edu> Date: Tue, 14 Jun 2011 17:17:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Farrell References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> <4DF740E5.4030309@cs.tcd.ie> In-Reply-To: <4DF740E5.4030309@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 00:17:48 -0000 Hi, all, It'd be useful to wait until these docs (this v6ops one and the 6man one it refers) are adopted by the relevant WGs before noting them in recommendations to external parties, IMO. Some of the recommendations in these documents are akin to "if I didn't expect it, it's an attack", which I feel makes our protocols too brittle unless we are in a situation of known security compromise via other indicators. The latter doc (6man) also silently discards legitimate packets (complicating debugging), and ends up deprecating the entire extension header feature of IPv6 for all IPv6 signaling protocols - which seems like a bad idea overall. I'd prefer to see the relevant WGs endorse these as useful ways forward before adding them to this list. Joe On 6/14/2011 4:07 AM, Stephen Farrell wrote: > > Thanks Nick, > > I'll add that unless someone tells me its a bad plan. > Its a fairly fresh I-D, but I guess it looks pretty > relevant all right. > > S. > > On 14/06/11 11:00, Nick Hilliard wrote: >> On 14/06/2011 00:09, Stephen Farrell wrote: >>> * RFC 6105 – "IPv6 Router Advertisement Guard" >>> * RFC 6106 – "IPv6 Router Advertisement Options for DNS >>> Configuration", §7 in particular. >> >> maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic >> focused document, but gives specific advice on a specific issue which is >> relevant to ipv6 lan deployments. >> >> Nick >> > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From stephen.farrell@cs.tcd.ie Tue Jun 14 17:32:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8B71F0C5C; Tue, 14 Jun 2011 17:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.125 X-Spam-Level: X-Spam-Status: No, score=-106.125 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HrSUHMbfnGN; Tue, 14 Jun 2011 17:32:33 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8021F0C52; Tue, 14 Jun 2011 17:32:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 57F1615356D; Wed, 15 Jun 2011 01:32:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-type:in-reply-to:references:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1308097944; bh=hm1ypKE3WAatZ8Py/YHfyYJh V7QSXt//EGcxhiHf36M=; b=pQbq8nUS8l9leztQT5v1eIfT+jMfMxr3ki6J5zeN ppamvXPtwDbwtONnidLBHABaC9ukuOQDlkLoZMqGvpLk3tn2um1kBe3ziYk3zI4n jXz0xlsx38N/Ppw7Qq9Xmfo9IamFeC900s9GMWa3hM+VAOh6fIJaotnu2tB60sPc xW0o/lv9iiTBx7jN09yfrSaCwiKQP7S/3bHiGbrYYcYD2aqrO1X6MeO/KznI9QyP wOiz0ym5rQzT4rlJ0hXxXoPtuGx7lQbfK73TAELgSRU989MUHG9DEofGcj5zIrp3 p+Hm3JkpcfkTDtMCD79tNUR77CW5gIAxoYAbhCWTCiPr+Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id st0l0XVxzUVQ; Wed, 15 Jun 2011 01:32:24 +0100 (IST) Received: from [10.87.48.10] (unknown [86.46.27.52]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D98F415356C; Wed, 15 Jun 2011 01:32:22 +0100 (IST) Message-ID: <4DF7FD96.9010700@cs.tcd.ie> Date: Wed, 15 Jun 2011 01:32:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Joe Touch References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> <4DF740E5.4030309@cs.tcd.ie> <4DF7FA0D.6040201@isi.edu> In-Reply-To: <4DF7FA0D.6040201@isi.edu> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------020404050002030007000507" Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 00:32:34 -0000 This is a multi-part message in MIME format. --------------020404050002030007000507 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Joe, Fair point about the draft-gont document. I've taken it out for now. Which was the 6man I-D you meant? There are now two referenced thanks to recent comments and both are draft-ietf-6man so have presumably been adopted by the WG. My current version is attached following today's edits in case that helps. I've still not included rfc 3514 but the more iterations this takes, the more I'm getting more tempted:-) Thanks, S. On 15/06/11 01:17, Joe Touch wrote: > Hi, all, > > It'd be useful to wait until these docs (this v6ops one and the 6man one > it refers) are adopted by the relevant WGs before noting them in > recommendations to external parties, IMO. > > Some of the recommendations in these documents are akin to "if I didn't > expect it, it's an attack", which I feel makes our protocols too brittle > unless we are in a situation of known security compromise via other > indicators. The latter doc (6man) also silently discards legitimate > packets (complicating debugging), and ends up deprecating the entire > extension header feature of IPv6 for all IPv6 signaling protocols - > which seems like a bad idea overall. > > I'd prefer to see the relevant WGs endorse these as useful ways forward > before adding them to this list. > > Joe > > On 6/14/2011 4:07 AM, Stephen Farrell wrote: >> >> Thanks Nick, >> >> I'll add that unless someone tells me its a bad plan. >> Its a fairly fresh I-D, but I guess it looks pretty >> relevant all right. >> >> S. >> >> On 14/06/11 11:00, Nick Hilliard wrote: >>> On 14/06/2011 00:09, Stephen Farrell wrote: >>>> * RFC 6105 – "IPv6 Router Advertisement Guard" >>>> * RFC 6106 – "IPv6 Router Advertisement Options for DNS >>>> Configuration", §7 in particular. >>> >>> maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic >>> focused document, but gives specific advice on a specific issue which is >>> relevant to ipv6 lan deployments. >>> >>> Nick >>> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > --------------020404050002030007000507 Content-Type: text/plain; name="ituipv6lia.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="ituipv6lia.txt" From: IETF Security Area To: Study Group 17, Questions 2 and 3 Title: Work on Security of IPv6 FOR ACTION The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 security issues". As the world transitions to IPv6, new opportunities and challenges arise. SG17's focus on deployment and implementation considerations reflects this reality. We would like to bring to your attention the following work which we believe may prove a useful basis for both X.ipv6-secguide and X.mgv6: * RFC 4294 – "IPv6 Node Requirements" (N.B., this work is currently under revision as draft-ietf-6man-node-req-bis, submitted to the IESG for approval on 2011-05-25) * draft-ietf-6man-node-req-bis (work in progress) – "IPv6 Node Requirements RFC 4294-bis" * RFC 4864 – "Local Network Protection for IPv6" * RFC 4942 - "IPv6 Transition/Coexistence Security Considerations" * RFC 6092 – "Recommended Simple Security Capabilities in Customer Premise Equipment (CPE) for Providing Residential IPv6 Internet Service" * RFC 6105 – "IPv6 Router Advertisement Guard" * RFC 6106 – "IPv6 Router Advertisement Options for DNS Configuration", §7 in particular. As you are aware, every RFC contains a Security Considerations section. In developing either an implementation or deployment guide, contributors are strongly encouraged to review the RFCs and Internet-Drafts that support any underlying function. In addition, we bring to your attention the following IETF Working Groups that are working on IPv6 security-related work: Working Group Purpose Mailing list address Name 6man IPv6 Maintenance ipv6@ietf.org savi Source Address Validation savi@ietf.org Improvements dhc Dynamic Host Configuration dhcwg@ietf.org v6ops IPv6 Operations v6ops@ietf.org opsec Operational Security opsec@ietf.org Capabilities for an IP Network In addition to the above working groups, the Security Area of the IETF maintains a mailing list for general discussion, saag@ietf.org. We encourage and invite open and informal discussion in these or other relevant IETF fora on this very important topic. As with all IETF working groups, any and all interested parties can choose to directly contribute via the mailing lists above. As in other areas, the Security Area of the IETF invites SG17 to bring any new-found concerns about IETF protocols to our attention so that as and when we revise our documents we can make appropriate amendments to IETF protocols. In particular, as this planned work matures, we would welcome hearing about it in more detail, perhaps via an invited presentation at a saag meeting or via review of draft documents as may be appropriate. --------------020404050002030007000507-- From touch@isi.edu Tue Jun 14 17:36:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EA221F84F1; Tue, 14 Jun 2011 17:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.994 X-Spam-Level: X-Spam-Status: No, score=-101.994 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUStbJKOsrRO; Tue, 14 Jun 2011 17:36:07 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A46F521F84EA; Tue, 14 Jun 2011 17:36:07 -0700 (PDT) Received: from [192.168.121.117] ([221.148.74.90]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p5F0Zn26026673 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 14 Jun 2011 17:35:54 -0700 (PDT) Message-ID: <4DF7FE65.9070303@isi.edu> Date: Tue, 14 Jun 2011 17:35:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Farrell References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> <4DF740E5.4030309@cs.tcd.ie> <4DF7FA0D.6040201@isi.edu> <4DF7FD96.9010700@cs.tcd.ie> In-Reply-To: <4DF7FD96.9010700@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 00:36:08 -0000 On 6/14/2011 5:32 PM, Stephen Farrell wrote: > > Hi Joe, > > Fair point about the draft-gont document. I've taken it out > for now. > > Which was the 6man I-D you meant? The one ref'd inside the draft-gont-v6ops doc - it's draft-gont-6man... There aren't issues with the draft-ietf-6man docs. Joe > There are now two referenced > thanks to recent comments and both are draft-ietf-6man so have > presumably been adopted by the WG. > > My current version is attached following today's edits in case > that helps. > > I've still not included rfc 3514 but the more iterations this > takes, the more I'm getting more tempted:-) > > Thanks, > S. > > On 15/06/11 01:17, Joe Touch wrote: >> Hi, all, >> >> It'd be useful to wait until these docs (this v6ops one and the 6man one >> it refers) are adopted by the relevant WGs before noting them in >> recommendations to external parties, IMO. >> >> Some of the recommendations in these documents are akin to "if I didn't >> expect it, it's an attack", which I feel makes our protocols too brittle >> unless we are in a situation of known security compromise via other >> indicators. The latter doc (6man) also silently discards legitimate >> packets (complicating debugging), and ends up deprecating the entire >> extension header feature of IPv6 for all IPv6 signaling protocols - >> which seems like a bad idea overall. >> >> I'd prefer to see the relevant WGs endorse these as useful ways forward >> before adding them to this list. >> >> Joe >> >> On 6/14/2011 4:07 AM, Stephen Farrell wrote: >>> >>> Thanks Nick, >>> >>> I'll add that unless someone tells me its a bad plan. >>> Its a fairly fresh I-D, but I guess it looks pretty >>> relevant all right. >>> >>> S. >>> >>> On 14/06/11 11:00, Nick Hilliard wrote: >>>> On 14/06/2011 00:09, Stephen Farrell wrote: >>>>> * RFC 6105 – "IPv6 Router Advertisement Guard" >>>>> * RFC 6106 – "IPv6 Router Advertisement Options for DNS >>>>> Configuration", §7 in particular. >>>> >>>> maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic >>>> focused document, but gives specific advice on a specific issue which is >>>> relevant to ipv6 lan deployments. >>>> >>>> Nick >>>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >> From fred@cisco.com Tue Jun 14 17:42:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54D821F8542; Tue, 14 Jun 2011 17:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.754 X-Spam-Level: X-Spam-Status: No, score=-110.754 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjYh4GmzLyLD; Tue, 14 Jun 2011 17:42:36 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6C97921F8541; Tue, 14 Jun 2011 17:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=219; q=dns/txt; s=iport; t=1308098556; x=1309308156; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=Z/RESjri8B8J6elnS7oB+jzBCx5V7NSIkXFMNCI4P8Q=; b=Gain37CwW6NXckQ3uB15n1eweBu2kDijkjBnqYfzLO/+RpAJdJyFfEic qH/yu/qyf6px5CRtxxJXUDoAFc5OrWahi0Jvfpm/FIO9VOP1QlWojStHY b+03EYfEbizNp6Ktv6dTKUpWaiOXRMT/YbiZu3UPGb7jIuNhk7JnEy0oo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMj/902rRDoI/2dsb2JhbABSplF3iHOhLp44hiYEhxWKNIRZizU X-IronPort-AV: E=Sophos;i="4.65,368,1304294400"; d="scan'208";a="465551729" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 15 Jun 2011 00:42:34 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5F0gTVE030497; Wed, 15 Jun 2011 00:42:34 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 14 Jun 2011 17:42:34 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 14 Jun 2011 17:42:34 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4DF77E98.8030300@ericsson.com> Date: Tue, 14 Jun 2011 17:42:18 -0700 Message-Id: References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF77E98.8030300@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "ipv6@ietf.org" , "saag@ietf.org" , Stephen Farrell Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 00:42:38 -0000 On Jun 14, 2011, at 8:30 AM, Suresh Krishnan wrote: > RFC5157 IPv6 Implications for Network Scanning Personally, I think that RFC has been overtaken by events. Network scans = have been reported in the wild.= From stephen.farrell@cs.tcd.ie Tue Jun 14 18:02:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5821F0C65; Tue, 14 Jun 2011 18:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.903 X-Spam-Level: X-Spam-Status: No, score=-105.903 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EtotTQsjj7q; Tue, 14 Jun 2011 18:02:10 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 91D1B1F0C61; Tue, 14 Jun 2011 18:02:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 875E015356D; Wed, 15 Jun 2011 02:02:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308099723; bh=Mj2C9ZnZ69N5v0 UR7zepE5rS2tIrBtpD/aIBFkclXrI=; b=1P9h3C9rJYdTOHdmCCtUtc43CJlsrc +wtzP4tEkZbqA+rQfYpu1s5VYtcK/AXOvyHC8wkSYiCrDtM1MrDiHlB9TNJSjkok 9L+CN8TiBIVjvtP5fz6jEQy8DCHm5oe2KvHOe3cwXDWFrOv6lDQLq/CVCrZW57ZY LD/GQoJS16qQ4FPna4she1X1SIUtUBNdFiBtGyRqpywKazPpWDNXHAkwiUdzp5bO O7aLIDfel+UdfAvtYVtZOuMf6kr2Aq8ztfkol2jF/F/blHPVLoksZ4STQmJCGIHA 4jcMTaTilXO86ksmo3rR1EzNr7ftZCzS8+JmBmCz+/Zk6AU7L/UUBLDA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id rJIjJSlGLEuV; Wed, 15 Jun 2011 02:02:03 +0100 (IST) Received: from [10.87.48.10] (unknown [86.46.27.52]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 5361B15356B; Wed, 15 Jun 2011 02:02:00 +0100 (IST) Message-ID: <4DF8047D.9000209@cs.tcd.ie> Date: Wed, 15 Jun 2011 02:01:49 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Fred Baker References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF77E98.8030300@ericsson.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" , "ipv6@ietf.org" , "saag@ietf.org" Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 01:02:11 -0000 All, On 15/06/11 01:42, Fred Baker wrote: > > On Jun 14, 2011, at 8:30 AM, Suresh Krishnan wrote: > >> RFC5157 IPv6 Implications for Network Scanning > > Personally, I think that RFC has been overtaken by events. Network scans have been reported in the wild. Ok, that's not currently included and given its not clear (to me at least) I'm gonna leave it out. I think we've accumulated enough references at this point - its never going to be a complete list and even if it attempted to be such, it'd probably be so long as to be useless. So I'm no longer taking additional reference recommendations unless a whole bunch of people say the same thing and otherwise I'm gonna stick with the current list as sent in a reply to Joe Touch a few minutes ago. If there're text edits that are *needed* then I'll take those for a couple of days more but I reckon we've iterated enough here. Thanks for all the help with this, I think we're done now basically. Cheers, S. From tjc@ecs.soton.ac.uk Wed Jun 15 02:45:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00F121F8489; Wed, 15 Jun 2011 02:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=2.499, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTP3JbvN7e+s; Wed, 15 Jun 2011 02:45:36 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1BE21F84DE; Wed, 15 Jun 2011 02:45:34 -0700 (PDT) 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 p5F9iNF5030547; Wed, 15 Jun 2011 10:44:23 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p5F9iNF5030547 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1308131063; bh=ZmTv3KiCfclrWyN5WvZkuPEk1ts=; h=References:In-Reply-To:Mime-Version:Cc:From:Subject:Date:To; b=Lr9LLzGKMi7Pl+TSo9GKXoMS92/zjfH2RffRFdMqh1pw048cdM8SAyThjI2irA6wZ tAV1FKD9MAUUvLWX/KVzSKNkVb4gTTCVGA07jUznprfdoM2dUow0GRAJTJlzbCM8iM NY0Tl/8Zljq877cIv9w45M07I40dRkp/3eBL9Fps= 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 n5EAiN0521310575Og ret-id none; Wed, 15 Jun 2011 10:44:23 +0100 Received: from cerf.ecs.soton.ac.uk (cerf.ecs.soton.ac.uk [152.78.69.39]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5F9iE7U028888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jun 2011 10:44:15 +0100 References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF77E98.8030300@ericsson.com> <86015668-D0FC-4D85-B078-74E6AB096D56@ecs.soton.ac.uk> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-17--888627372 Message-ID: From: Tim Chown Date: Wed, 15 Jun 2011 10:44:14 +0100 To: Fred Baker X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n5EAiN052131057500; tid=n5EAiN0521310575Og; client=relay,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p5F9iNF5030547 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" , Stephen Farrell , "ipv6@ietf.org" , "saag@ietf.org" Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 09:45:37 -0000 --Apple-Mail-17--888627372 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15 Jun 2011, at 01:42, Fred Baker wrote: >=20 > On Jun 14, 2011, at 8:30 AM, Suresh Krishnan wrote: >=20 >> RFC5157 IPv6 Implications for Network Scanning >=20 > Personally, I think that RFC has been overtaken by events. Network = scans have been reported in the wild. I just re-read the abstract and conclusion to 5157, and I think = everything stated there still applies. The bit where we stated that we'd not seen traditional network scanning = at our own site (to ::1, ::2, etc) is the part that has = changed - we could now say there is some evidence of such activity. But = that doesn't invalidate the advice to - for example - not have your = DHCPv6 pools start with ::1, or the observation that attackers = will look at other ways to glean addresses, with some discussion of = those. The interesting newly discussed issue since 5157 was published is the = possible impact on ND caches of scanning dark space, should such sweeps = reach the target subnet/link. WRT the ITU-T doc, I agree it's probably not needed. Tim --Apple-Mail-17--888627372 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On = Jun 14, 2011, at 8:30 AM, Suresh Krishnan wrote:

RFC5157 IPv6 Implications for Network = Scanning

Personally, I think that RFC has been = overtaken by events. Network scans have been reported in the wild.

I = just re-read the abstract and conclusion to 5157, and I think everything = stated there still applies.

The bit where we = stated that we'd not seen traditional network scanning at our own site = (to <prefix>::1, <prefix>::2, etc) is the part that has = changed - we could now say there is some evidence of such activity. =  But that doesn't invalidate the advice to - for example - not have = your DHCPv6 pools start with <prefix>::1, or the observation that = attackers will look at other ways to glean addresses, with some = discussion of those.

The interesting newly = discussed issue since 5157 was published is the possible impact on ND = caches of scanning dark space, should such sweeps reach the target = subnet/link.

WRT the ITU-T doc, I agree it's = probably not = needed.

Tim

= --Apple-Mail-17--888627372-- From lear@cisco.com Wed Jun 15 08:10:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4811011E80DC; Wed, 15 Jun 2011 08:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08MdA-6Q18xq; Wed, 15 Jun 2011 08:10:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 07D2811E8117; Wed, 15 Jun 2011 08:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=646; q=dns/txt; s=iport; t=1308150648; x=1309360248; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2c/Ay7D0sEraqeWcowjTYMYOVsjeqe/n+VpClTuipdo=; b=h0EGVtRlNS90wnM2wft3DcfmBVo0VHuV3j0ahp1mwEpuMhj8Cxcpzf9f Wh8ZMW10qbtGz8ww84xg2nzY6ftcQe1Y04ukzRiJXftPNMVjHgh/V0kW9 fVQbIkjbBQHSTHNYQ4smdTXM4V+okxAyUaeDo3T3RJ3STd15XrqzNqxms Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOPK+E2Q/khM/2dsb2JhbABSEIQ5ogh3qTuNK5EQgSuDcYEKBJFOjzs3 X-IronPort-AV: E=Sophos;i="4.65,370,1304294400"; d="scan'208";a="94113869" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2011 15:10:42 +0000 Received: from dhcp-10-61-101-58.cisco.com (dhcp-10-61-101-58.cisco.com [10.61.101.58]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5FFAfst016460; Wed, 15 Jun 2011 15:10:42 GMT Message-ID: <4DF8CB71.3060806@cisco.com> Date: Wed, 15 Jun 2011 17:10:41 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Joe Touch References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> <4DF740E5.4030309@cs.tcd.ie> <4DF7FA0D.6040201@isi.edu> In-Reply-To: <4DF7FA0D.6040201@isi.edu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" , Stephen Farrell Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 15:10:49 -0000 Joe, A suggestion just on this one point: > I'd prefer to see the relevant WGs endorse these as useful ways > forward before adding them to this list. > It is good for the IETF to provide the ITU's membership an opportunity to comment either formally via the liaison process or informally as individuals before work is finalized, just as we would like that opportunity. So long as we are clear on the status of the work, and the work can reasonably be construed as relevant, it's okay to mention it. Now, how should one apply my advice (which is what this is) to your suggestion? Regards, Eliot From ietfc@btconnect.com Wed Jun 15 09:25:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E21E21F85B4 for ; Wed, 15 Jun 2011 09:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3MRtRK8gsxA for ; Wed, 15 Jun 2011 09:24:59 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id 87FE821F85B3 for ; Wed, 15 Jun 2011 09:24:58 -0700 (PDT) Received: from host81-156-207-154.range81-156.btcentralplus.com (HELO pc6) ([81.156.207.154]) by c2bthomr13.btconnect.com with SMTP id DFP33177; Wed, 15 Jun 2011 17:24:40 +0100 (BST) Message-ID: <000701cc2b70$0b342500$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Eliot Lear" , "Joe Touch" References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> <4DF740E5.4030309@cs.tcd.ie><4DF7FA0D.6040201@isi.edu> <4DF8CB71.3060806@cisco.com> Date: Wed, 15 Jun 2011 17:22:24 +0200 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=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4DF8DCC7.00AA, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.6.15.154518:17:7.586, ip=81.156.207.154, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4DF8DCCB.0162,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: v6ops@ietf.org, Stephen Farrell Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 16:25:00 -0000 ----- Original Message ----- From: "Eliot Lear" To: "Joe Touch" Cc: ; "Nick Hilliard" ; ; ; "Stephen Farrell" Sent: Wednesday, June 15, 2011 5:10 PM > Joe, > > > > A suggestion just on this one point: > > I'd prefer to see the relevant WGs endorse these as useful ways > > forward before adding them to this list. > > > It is good for the IETF to provide the ITU's membership an opportunity > to comment either formally via the liaison process or informally as > individuals before work is finalized, just as we would like that > opportunity. So long as we are clear on the status of the work, and the > work can reasonably be construed as relevant, it's okay to mention it. > Now, how should one apply my advice (which is what this is) to your > suggestion? Eliot I do not think that it is enough for us to be clear on the status of the work; it is the other SDO that needs to be clear. We know how to interpret a 9 month old I-D without the word 'ietf' in its name and with an intended status of Experimental. The ITU-T do not. So Joe's comment that the WG should endorse the work before we liaise it I think spot on (and I think that Stephen has taken this on board). We have arcane practices and terminology that are incomprehensible to other SDO so we have a responsibility to make things - such as status - clear, in language that will not be misunderstood. Thus we know that the first draft adopted by a WG is almost always wrong, simply because the adoption process forbids changes; you must wait for -01 or -02 before you have something that starts to resemble the views of the WG. Obvious, but not to another SDO. We need to spell such matters out. Tom Petch > > > > Regards, > > Eliot > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fred@cisco.com Wed Jun 15 09:40:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079F211E812B for ; Wed, 15 Jun 2011 09:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.749 X-Spam-Level: X-Spam-Status: No, score=-110.749 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1PxTX5xM2uM for ; Wed, 15 Jun 2011 09:40:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF1611E808D for ; Wed, 15 Jun 2011 09:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=111149; q=dns/txt; s=iport; t=1308156042; x=1309365642; h=from:subject:date:message-id:to:mime-version; bh=D0b7q23UnoMLrbm/I5/OonBQxQ2ij4VtTjc/byZr+NI=; b=YU1c96+0o/XbDoVoD7eUWrp+x6l2NmhT3SDSHpFbAht5fNMDL2WHU3+2 rBKveDXbmyDpQ+NqK1ZHglhexk++bkxogqTH99SfMTUmcg+ObvbCF6W40 F7KUeCP18y8mKAhu1C27ecv/x3SeiHrtwPw7tyQ/7JVX5EaCJhkGig5JD w=; X-Files: SurveyMonkey - Survey Results.pdf : 80535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkGAEPg+E2rRDoH/2dsb2JhbAAgMqZVd6kNgR2eQ4YmBIcYijaEW4s1 X-IronPort-AV: E=Sophos;i="4.65,370,1304294400"; d="pdf'?scan'208";a="714007707" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 15 Jun 2011 16:40:31 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5FGeN7l018813 for ; Wed, 15 Jun 2011 16:40:28 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 15 Jun 2011 09:40:28 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 15 Jun 2011 09:40:28 -0700 From: Fred Baker Date: Wed, 15 Jun 2011 09:40:13 -0700 Message-Id: To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/mixed; boundary=Apple-Mail-618--863668135 Subject: [v6ops] Survey from 6 June X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 16:40:44 -0000 --Apple-Mail-618--863668135 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Reporting back. At IETF-80, we had a brief discussion, and the view = expressed on the floor was that people wanted drafts we discuss in = plenary to have shown interest on the list first. Hence, whenever a new = draft is posted, I send an email (well, a bot that works on my behalf = sends an email) inviting discussion. I also ran a survey trying to = isolate working group interests. Attached is a summary of the results of the survey. --Apple-Mail-618--863668135 Content-Disposition: inline; filename="SurveyMonkey - Survey Results.pdf" Content-Type: application/pdf; name="SurveyMonkey - Survey Results.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNXG1v3MiR/s5fwUPgA41E4+H78L4c9i3BHnCBsysgCLL5 4MjSnnOWZUta7x1wP/6e6q6n2GyyNeSMFlksjOEOu7qqq5566eoefcr/lH/Ky0Pe7Hdl3+3rvO27 vK/r3aFq8vvr/M/5h/zVVw9lfvWQl+6/h6vU+Azjb1IvZTL3sq/a3b7Jm7LZ9VXeHHZDt99X4+t9 u2vazslRDrv2UA8HP3FV70Q2vu+aXXPIOcTou67d9WWVt025a5q87Hb9vgE/sk+89yz2O6hgqMou X3ryK5cJyhoCegb7Xdu3w+FwUA55mZU5RlaQvcq76rCrZJl+tVh63dTD4MdOh/iJhkOdB6OyG52o HbCcPeykE8Fc7TD0fqL9roLA/t/Iej/sDqbnEsruh65TG9GS9X63H7AWzD64wfWu7aDVHlLb9F7O tqmgUJOAhqPiGkjg/5kEEcVcU5BiHIyFVcBcecBKoE1RXNVw9gNm9/+SBMnpRQ/QXEsG7X43ACBP MUiQpFjU3V6wTA51tzt0zb58ikWKJMli6OELjfFoul3Xdkd4pGhSTLyhm0O33grhYJkWIg21uYIa WNXpxq7Xfjg8NbWqUYZu0PpkeHJq1Z4M3qLtyfjU5Krptt/1iGmrMd9EBMnpqXGO36D1iCTFgprX 4Vu0H5MkWdACSrDJCjFNiolaQj4Qr9dbIiJITk9LcPwGS0QkKRa0hA7fYomYJMmCllCCTZaIaVJM ZBwy5b7c1RVS0No8EBMkp6clyGCDJSKSFAtaQodvsURMkmRBSyjBJkvENCkm3hJ1X+9KVE6rLRET JKdXS9j49ZaISVIs1BIcvsESM5IkC7UECbZYYkaTYqKWaJodSqL1hpiOT05OO+jwDWaYUqQY0Ap+ 9BYjRBRJBrSBH7/JBBFJioVaAPsI1FsbTBARJKenDTh+gxEikhQLWkGHbzFDTJJkQTsowSZDxDQp Jt4S2BvsmnpDpo4JktOrJWz8ekvEJCkWagkO32CJGUmShVqCBFssMaNJMVFLYNdTYWO1OixVEUFy elqC4zdYIiJJsaAldPgWS8QkSRa0hBJsskRMk2Kilqj99n1iCeubcOcsn7Z7riISz8D6JOwPVDQF h4emSHJIECV40BbKYmqLFI8UUYoHjaFMpsZIMklRJbioNfauUTUxxlONjGo6PjU3laqjQ0MkZl+m SMxPhfrpp0ZYnj9BkZqfuvQMpgZIMEiQJDh47Zd9u2vRnlut/pggNbtq04avN0BMkuCg+uToDSaY kaQ4qEI5fosRZjQJHmqFpt/VaLKtt0JEkJqdVuDwDVaISBIcaAUdvcUKMUmKA62g4zdZIaZJ8FAr oDu+37JxKCOC1Oy0AodvsEJEkuBAK+joLVaISVIcaAUdv8kKMU2Ch7fCgMSLdnC93hlmFKn51Q7j +PWGmNEkeKglbPgGU8xpUjzUFkawxRhzogQXb42u2sEYW6wxo9D57dAqLpZGgvXmmNGkmKg9bPwG e8xpkkzUIEaxxSBzohQbbxE7erRkgYOmbrkk8BQ1jv5KOawkRZKBOsjIghZ5goXSjEyUJsVELWI8 RoukmSiN8TCaJBO1iHEZLfIEFyUyNkYUsdFD4OWjWTmDSx0D923pqy2w6HE8hb18jxNUPQzdo5Nb 4jxRjlP1KcMTjog67BuxF/mEF3LgvMd/F/4RZ9F93+RXt/mXl3mJE0V5hc9yn+OI7fI2f/X7creH y13eZH/Ni//835f5RT3surzI8YTzlLz4/qeXmLfKi3t84x4+8+GaD0LmXj28zP+WX/5H9s2lOwp/ Wh6clspZ9SWOwAPJyiEUDce/lzc5RPvi7dv76wfMf9HvvXSHvPjy7u6/Pcf8KMdsqoGqaUM+TgXC Z0kFX3B5V/4hK/QhL+5UOVTSB/3/xxPFqttlsV6/14nfUBZyEpUAia0oJfMm+1d81WHbFFjxtVnv nU5kS+AXnPDH0IanXGiokUQ6OcHtO9dcQm9wwAH4IR92uAyAbKHn0ALXGl7SDPLUtPvh4I6wj+E4 wA1O6R2icTeg6/O6HrIJpvPi67ufP7y/e/P2ZX75D48Ru3dRY/da41IDxWwHd1TyTEKiXKdobdcs iAasfUVbmnHMo8zMj/JV2zhT4iCHNFnxXzEgbJIJ9sQt+e+pGJFpjBjFLnt0o/adjxKVRglxkb8A 9N7dgXrIJsEB4UKkg1DyJitM/s8i/wEXJmyMvKqwoXFfSLQ44rtzyaoGyYqSMX6JZF969ogWfPj+ W1WT6LrFZjajqCahOYI9rHNqBN8no+2oybrBDprymiaL/zNQZscgH6Cp7tqFybD4S7fSTELSxaEO jHJvqLo1y3mzVGoFMR1Q40K4mjAvrhFOKmQgMxxCkDc7IoZ/uLUnUks0QmefSjZ+N5jsUPko5ZAy QYHw//KLia1mg51wV1c6Y1YI9tx3iFv+ATJc4JxzFNhMbEMQB6Zg/BFyuVlMRzILlj163JxRWhGZ qdHmU5YuPruVf6K8NrGNfaAa31EsU6At4eF3ImCjOXr0H0SbRDg9AlSs3/LwiNm+Qb+BmKWPSY3w 08cf79+8FZEDO3+4+/lfwozn0saAW1USmP0Vsqo8uGM3+CC+vb/OwipITMB/T0UprWQqCa2oZPAJ Kfs46kPKP49oduY1KIh5O3WOiwqR61FUrAVPhcj1aEOZclFiIGA5TDsKG/B3ZYIZHBMY1H06CB12 tYs1UxJ5VUrvWDzEvWKA+uZSqX+PF7gy6OOjG/IbouGAV45DGSr7WPAItTUs6UtkYXpMw0jwtVRd LsRn5HpYZZ45vhFncAsIA4dhOBPY6MYSpXmNu3MdbIUrfkNeojSu9GqjQ87r6/ur64+PP715n9+/ Ax3uEaJkFliU2JSi/MBENeTtUM8OdSdSvvr2tsy/vkNp+uq76/dvHt99vv7q7v3d/bvb68f7d1cy z6vXbx4fr+8/yA3NV6+lHPmQoxoH1HUef8dSefhC5lUsipM1FOXQ4GIgbhjaJF6YygsT2k9lR/wW 15mIXvvRoqO63R1EpAZhXi4RSoGFSh9XOPsBS462GN5ZxK2ORIKydEJf4LPGfbuq9Rasg9z/tY9V ZVbcCFwBUvMGh36ETR8dS5dRLiCp9xyIisHfOfvjQafJi48O2yDzkQ6vluuYlYVoNrlZi+643LxF i8KBCbeY9oImIsTdYuVFS/mEjkrStG4niOpQaQT97mqqN7qNi+d2XrJvuGuLx/lpBpSE3tQ6mxxR AbOU1E8i10U8llXSDvd1D7jTKvV1/PRwdbSKQKA/IJDJhmsM9KjIR1OHgf63iAoloCDFFHgW8F39 0GDoXsKi8i3sKR8f/QdsKf8HSx4QBBHzzMUlQDrRXbyfPR2J/bKHgz197G9yCf/Y3bqS38oqBH+P MsR2jzI8PEAwH3g8zBDnx4Qqo2rcnPYxuXQbJ9n1eoLbW0P4Pfa5k5XIauBT1ard96jyFr5bAQHT vcpfMy3hxl3lJBdJ0ezzhpRL34/vRoex9b6FV6EwH4uOTbv4f8PaUbL7pPi37GiFrll5sY7osKcL 1+o39EVVjSknjH/QuSSZad8i0FzdwuQH05y1B5g8mYpH7Ug4mmjOdl0ce+tNnQl6xZgSwdynqdNt wtxXrpqrQjsw6ZsVPjNbG7m1R6aKPb71gWJd22JUgFNnoADrW0CfHq/yMDG9bs1+KEoKtudYe3jB b354GUL8KctEglVDXu81YTCKyJbsNaKHF+wPqtVvnBYQHiCYepNL/N7yzrefBkGP9DRjhdX5GmbN XGO7Ca5UN3vDk6kTs4nUWbHDQ+WF9c2VuLJEJeOQYbtHv4EKSTzQXMpE0czi03XXHrmNN7DIDsrQ h18UaOHpRgN97tXdSxd1xjYUQahQDiIfwpwjebR5fwcGmFfDHeYNdus2yB5mM3O9nBjtIuk/wW2s /8QhUuzicpErdZ38XKxFVGGDDne4RnlX4lcrvnh2ZPRLOqwJN2PwLTHGeCDFNE75uqy4wBO2Tchn VkUL/CMNc7lkSY2bxAgFumMUPULQsFfK0RB0zBNHnWiKRuSGKC/khQUQagBiejTCh/zDzwoJE5T2 ER31gbV1xwM2o10oNw33wDUaqKkXU72zHNs6XgRj7cwy6BZa3mVF0jCBFL+BpA6rZiDxQvROin/H p9w1CTD2BQfTUsbdArETA9uGgMWNvaRPisdEvdKfzcu86xiNbASdgNQTdSw+gB9U+eaSVwa+ckON ODCdewG5BY+hdDSD0gR+eTN1X8AOODbbz4OIvVIDLrQLuQYTUCza1hOkUBMc6xNj5kp82MP3SCLj TxDiVkrsTIJTh+ZrYE5bgplRrOf91RZDMbD1mMYVpc6k4FvneNF5iKSByYFI5k8dqAAaz5R1FApm nqw4BQpcqmgTyApVRdBRJlGUnBQZx7wgNYeO9YtBa55vxkHAIXokYQYLJpTzoZDXG8QKidcBe2mp EOPuk+QWTiR2SlgOiXxyCEC/gAB6CBnYhAsY0zBtOgDLaRykVKGONZqSj2opEIpvdpjOsuhJmGsA OIAuOrFAyfRHTO3UxlU6y0RBaslh0K91Cc4cxnyRM01cMEp9HCPeJVVKkICN2Rw18k00EVXECa+Y TRaMpCs1I0HiFcpky2maOXE3Z5Y5LZyY54rAPX7wadAb634bQ8nZ4LNZ+IUPhD4xwzBjjZMVHGKq Qj+JBhUGU9SbhagbghJECmCoEycXJm5e3FA8mQ4WDx3V5uOYm0cfwzILCrZKEYuxRXFPKhtjUOIb QMHXnpNFObjaWKZkasnUZ+6qxFlh8sKfVhieJ9njhqjEbqCp95EXSW5kR/Op+sulgXGyBkeR88ng kn+x1a4D6GRHnE0bLl3ZCpMIq8UfoeGjIivwl3faOAFtsFWZ+kDx3fXDx7sPD1jAebNj09nUaB6F dwZwHHn30wfE6bVTB30npNyGPeJww8joYRA09Ny4hIAmiC/mXfeR7mL2ebyRQt+9s3sKnfsGTkoQ E6BS5/ojLiOabVE4lp9Si+MgEU5nNIZmq9NNHEYDWwR9gp/r8MSAN0K1RRNuUX9WPLdcNVzL+Wfv v8iKF3hAf8enbGkm/VCYitY3AOA7iAQLR0fdHl7Easr6cgV+MV6D8wlQ6dBckB8CO+zZhHBL6Wlo Blkp91yRvfy9BgLRJi+grBMkhTJb/Js6CQT9J4OaXkIMTzzDn7QamC1G+8GupnbHXzbCPJPuxNw1 TXRouqFONKq/a96gLOuAPw/4AnzoOAr40PFR4OfLwNc0uxJAk8getdIF+G1VetFGKK0F/nytAvy2 bqMJTwK+nzwLArAA38A6SrsG+Jgsbv9hrj7ODpuBb1GS9eDMbyyw+qoGnX0EAH9cf+EKJsTlCbon hTTxr0QhPC0A6uYlKxqZ2d1TMQyfhnx268j9kS5A/8FqV9c+oQWdKyxp3UK/hvxc2phOExYvX0Bb UQ6QBbtBp7hCXOSIK+Cm3jRkF/irJ8PpOUD+ZMd0QucK9Ua5l3OAwXebK8wnQ/zvqoUm3gzLhval wsbCMAsSQz7QoldpDJdLiPdVOjG3gHj6mInxaD4gSPBnCMoiuPHIGSHPatCG540CWujnifhtgZyg HWhgQCcG7YHbpFNAuxC/u1Jvk4wwwHF+uQa0y/G7q+tfLn4b0EZpoayjhcti/O76heObM0HLCMdo /eE8yJpTGGZZRuNTkIEOsSHWXeyRNrfxNCqL47dEFvxjBZrnzu7QvKQ48yV7IJo1Ji+W4aeF4HQZ 3uEKzTRiFnK1aA2a52uVaqQ76LVxA5wLwRX1uNIL55NLNWIItMllX3IUzfPJEIJ73BM4swy/IbiY rxkxpd3vz/EMWp+pADN3nPUXIjBDu20buVs0fJKznOejFkEXyDg+MdaneradEah9Wn+rtNl4xYb+ Oa/g4fgnO8Si7k0xhhU6hFYriw5hlcxKYGmZm9yX9qUWqSPEauj1dIfocVNq6mHPWJOYIkdpkRxP dIg+bg1tLs+JKKKG/vAIhCFHBuBccgdB5dhrXXAHQ73EaZQfaEwY2smaQJVTB1erGhEAm+jLBDsC ywDC3tF7D3O3pt3/Y00rcD9P9ZIIeqfibPxNjVyAsBLcSm/i3oI90BeXNeYTm3APFSf6MT3+WOEU pgX+ZF+3BvfztUoi6A/aczVonpQI1F+jbalXJH6cZJOv6sdgsvm29IBLvmcmAsZpgO9C/tBhgMsU 0N1VOAeohR6jYdbgyDKL8Z4wF5hO+jNjG98QbA8ksoAvb3CiG2YNMsC1SyddKP/JuIeKnyjnZ7i3 +n4B9wP9+plwfyjj7kmBe+jV6bg/VPH+4BzcL/prj0uXhtrRA0oo8rTQf8AZyZku8A/tH/DzFtBy AEIZElcmIab8oBW1kJX2TC7Gwd6otwSHRpJ48Pddwz7OCHBfBU2EmbiSXJLSJPI/XE2wuY3SC+c1 52LyU/F8n1Q9/vQUAlM94UqaFcZ2jiWXBVfquLrnciX8ijhKIed1Ng+9dnEN486VLF5skjvsi8le wjBvk5+eQgZcND7TfwzNFvLHGz2M2xbImW+IuVtaUoh9084Kowm+HfzoQMSyTDs55MKN7HkGIpxN CDJf6laax4v/oONqTnG6IwUdJsx2ciqCqX6t/jOUcSNo9ZHYcgmGH9VGDvmM/mOYfw7/6fS3QKef 8xoszX8MwgSqXcmyIbavlt1C737Wfo7fsKYL9s8G/BtKIR6ArcC4c2FpZ0PZVdAvxvthJveSy63w iHkfBL+Yyocl5VtHtWbm46ZEv1jcjFtktp3LyhCtki1WOx3+PvzQxV2lAhfaXpxU78jmRH4ENU1V J3nGU2JLkWaqHX2kRIo+rUgr98haZ2YZ8xKmFEb1Tw6Vkx31UuI4emZgtRiTDBmMR7/+G+QYEcb/ Dtmc7sS848XCxCucYB4qZWc+Ua79aMSqpyr2AnsDDMZbc9u+APzZeomWwY9jMsgm5TnaBiOM5Nxx DfznqxX4l/sq3vU4/Juzr3RbP/tyd1nwP2p1lPz0XQp+bXz2AfIv7gAM8+Y9+EJ6VWHEVyFcr2s9 PoIWiEdsoA1DrGHPQvFON2b2ZgGxFu2fDbH4zWCE2PN21eW+jzcXDrHmmM+GWGr1WRBbInedGbLH H6oxlFq0NIx1DE+MumNpP7u/xlnGYsKoJWtPTnUnhbtuhTn1NXnO6ix7Q1aWFPSN26CfDvxQqb82 4JeI188L/LKKdwW/DPBNq88DfPwRknOBbzi6JdSIPVbIDLYAmu04pe3k7vgoXg3dc9+Itr3jzyIs S3iayaHEGbjtNOmGuxwTzx5209uYi5fSGm74N4W9dPe/LNu41bL6HDhRYpT85YLh6RzcBslPmjcA q+LLZl91EgxZ5wcAZYU/L3YmWIOdpPY9GfzkLDhqK34mns3mK/qfNxawDZ3uPg7mDq8as29PV+En 0Q+nWo3gsGUmO8VlRVnxYLmYCK65zoW7ZFafGNVKKD+155KtYlntZye4uGj64qRtlyuWq2rxBNdW 8AyCu2LZYDhiuoQKT9wtVt3Zx7m/GlDjpo7f4hHFTADiCjhwC0+WzTssfXCwfhE0Ek/so8wjnveO TjN1GN/T3mFvAM14C2m/xDcXWgkyFW15L+m8o52d8/bn3F4r8dc6nrHJuCi49w7iOfAOFKz0jj/9 PwXlkYQKZW5kc3RyZWFtCmVuZG9iago1IDAgb2JqCjU3NDEKZW5kb2JqCjIgMCBvYmoKPDwgL1R5 cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDYgMCBSIC9Db250ZW50cyA0IDAgUiAv TWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovQW5ub3RzIDggMCBSID4+CmVuZG9iago2IDAgb2JqCjw8 IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNw YWNlIDw8IC9DczEgNyAwIFIKPj4gL0ZvbnQgPDwgL0YxLjAgMTAgMCBSIC9GMi4wIDE3IDAgUiAv RjMuMCAyNyAwIFIgPj4gL1hPYmplY3QgPDwgL0ltMSAxOCAwIFIKL0ltMiAyMyAwIFIgL0ltMyAy NSAwIFIgPj4gL1BhdHRlcm4gPDwgL1AxIDIwIDAgUiA+PiA+PgplbmRvYmoKOCAwIG9iagpbIDkg MCBSIDExIDAgUiAxMiAwIFIgMTMgMCBSIDE0IDAgUiAxNSAwIFIgMTYgMCBSIDI4IDAgUiAyOSAw IFIgMzAgMCBSIDMxIDAgUgpdCmVuZG9iagoyMCAwIG9iago8PCAvTGVuZ3RoIDIxIDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSAvVHlwZSAvUGF0dGVybiAvUGF0dGVyblR5cGUgMSAvUGFpbnRUeXBl CjEgL1RpbGluZ1R5cGUgMiAvQkJveCBbMCAwIDQgMjJdIC9YU3RlcCA0IC9ZU3RlcCAyMiAvTWF0 cml4IFswLjU3NiAwIDAgMC41NzYgMzQuNTYgNjM5LjkzNl0KL1Jlc291cmNlcyAyMiAwIFIgPj4K c3RyZWFtCngBK1QIVChU0A9ILUpOLSgpTcxRKMoECpgoGAChkRGYSs5V0PfMNVFwyQcqDgQAbOcN WgplbmRzdHJlYW0KZW5kb2JqCjIxIDAgb2JqCjUxCmVuZG9iagoyMiAwIG9iago8PCAvUHJvY1Nl dCBbIC9QREYgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvWE9iamVjdCA8PCAvSW00IDMyIDAg UiA+PiA+PgplbmRvYmoKMjMgMCBvYmoKPDwgL0xlbmd0aCAyNCAwIFIgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMCAvSGVpZ2h0IDIyIC9JbnRlcnBvbGF0ZQp0cnVlIC9D b2xvclNwYWNlIDM0IDAgUiAvU01hc2sgMzUgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRl ciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB5ZO7jtpQEIb3AaCJRMUDwBvkHaiBZwgFokFKhyig ooMKIQo6JHgREAKJGGKzXJRwWZM14WKuBqJ8+LBnrShKVmnzgazDzPlnxjPDw8O/8/FtxGKxYDD4 S5rD39jv99vtdjQaFYvFSCTilFuWdbbOdy7ny+VyPouvsOG3jscjGTabTS6XC4fDUr7b7YgskCXk 8/nD4W7kAnkRLpfLer0e+fCaerNeY79jmhyq1arb7a5UKsK4tkFoGEa/349GozIvRsEKlqvZbOb3 +9H6fL7pdIrruw1CXdc1TaO1UovRZmHwWSxwvXshHo/jejaeYT6fTyYTVVUTiYTUEg27g2+O8xyv rj9RzHg8Hg6HrVYrlUpJbc/m8Xf0HnuYxQWq7XQ69CqTyUgtZQgvT3HTeR+Jpqnq5xufFKXRaGSz WamldYPBgHoEyWTy/Qu8Ly4uAAHJQs2MT2q/2vA6gna77fV6XS6Xx+Op1Wo4v9gQGTneUqkktU82 dk/uD6piRul0WrhoFMMiMmvZ7XbL5bLUMr3X+d5mvOInC8B0xHAZHGeaTwRFUQqFgtSyh6zr6XS6 La4DLICL1RQ7SZBmsxkIBKT2xxu4Xq/8McjuTEoEuf9/OJimyXRCoZDM+H8efgJz+LI1CmVuZHN0 cmVhbQplbmRvYmoKMjQgMCBvYmoKNDgyCmVuZG9iagozMiAwIG9iago8PCAvTGVuZ3RoIDMzIDAg UiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQgL0hlaWdodCAyMiAvSW50 ZXJwb2xhdGUKdHJ1ZSAvQ29sb3JTcGFjZSAzNCAwIFIgL1NNYXNrIDM3IDAgUiAvQml0c1BlckNv bXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4AY3PywqAIBAF0P49f9Eg sI0xMYGCttBF9riNRC47i8tdzaPrPkqpXqDsjaOU45VzTinVDCHEGJHgna+cc8y8Cl6ZiJaKaHho rRHD2Jhexhhr7SxQMKeOQmLRJlBwyylQrkZpfF/9azd/XLheCmVuZHN0cmVhbQplbmRvYmoKMzMg MCBvYmoKMTA5CmVuZG9iagoxOCAwIG9iago8PCAvTGVuZ3RoIDE5IDAgUiAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDkgL0hlaWdodCAyMiAvSW50ZXJwb2xhdGUKdHJ1ZSAv Q29sb3JTcGFjZSAzNCAwIFIgL1NNYXNrIDM5IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4Aa2QzYqCYBSGuz63XoV4A7ZKQl0IbhJEgrbehOsQ FFFBR6NZWDkVoaUyRjj+zOlbHJpZzWLe1fe9z/nhvJPJX8WyLM/zs9lMFMXXHo7jVqtVXddfRIgY hlFVtWmatm2BdF2PaDqdmqZZVdUn0f3eIBIEIYqiPC+u19tT5Q3RfD4PguB8Pl8ulxwqigKRJEmu 6x4Oh9PxCAUgRLIsr9fr7fZ9v9tnH08hUhTFsiyYGYYhLH2LIkSLxcK2bfDjOE6SZLPZINI0DXaB v4WhRIggB9/3wU/TdEeEyDAMmAZ+lmUnIkTL5dLzPPDgIrgYYkFEUZTjOGVZPh4PkmGHCB66rkMO fd8PwzCO4yuCN03TcB00dt2Prl9l//79Bm/q6BwKZW5kc3RyZWFtCmVuZG9iagoxOSAwIG9iagoy ODgKZW5kb2JqCjI1IDAgb2JqCjw8IC9MZW5ndGggMjYgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggMSAvSGVpZ2h0IDIyIC9JbnRlcnBvbGF0ZQp0cnVlIC9Db2xvclNw YWNlIDM0IDAgUiAvU01hc2sgNDEgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxh dGVEZWNvZGUKPj4Kc3RyZWFtCngBTcqxCQAwCABB53XGFDYiYiHYCCLOEkmVK58HAESsqu7OzIhw dzMTkfMQETOr6vYdZmZP+FzTEifxCmVuZHN0cmVhbQplbmRvYmoKMjYgMCBvYmoKNTkKZW5kb2Jq CjM3IDAgb2JqCjw8IC9MZW5ndGggMzggMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggNCAvSGVpZ2h0IDIyIC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9JbnRlcnBvbGF0 ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFt CngBY2BgYPhPBTAdCIyBgAkIgEYyAACIeUbtCmVuZHN0cmVhbQplbmRvYmoKMzggMCBvYmoKMjYK ZW5kb2JqCjM5IDAgb2JqCjw8IC9MZW5ndGggNDAgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggOSAvSGVpZ2h0IDIyIC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9JbnRl cnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBY2BAAkwRp3/9B/KZ1v0HAiAjBkQDGcy3oAy2v1CGAJj+z8AoQh4Dag6jyFOogZzr oQyWnOsgFgMDo0Lvlqd/we5RrZ46fTrIoYxsCobGIAaQycQEYQBJAOjHYYwKZW5kc3RyZWFtCmVu ZG9iago0MCAwIG9iago5NAplbmRvYmoKNDEgMCBvYmoKPDwgL0xlbmd0aCA0MiAwIFIgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxIC9IZWlnaHQgMjIgL0NvbG9yU3BhY2UK L0RldmljZUdyYXkgL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFj+I8OphszMQAA3zIRvAplbmRzdHJlYW0KZW5kb2Jq CjQyIDAgb2JqCjE2CmVuZG9iagozNSAwIG9iago8PCAvTGVuZ3RoIDM2IDAgUiAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIwIC9IZWlnaHQgMjIgL0NvbG9yU3BhY2UKL0Rl dmljZUdyYXkgL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAFjYMAE/5HA78tZrCAVSEIg5k6QIJrY/2wsYveZMdX9BWpG 1/tfAIuYCCOmOjqI/cVix1MsYhs4Mdx8I5sFVezvsy29CowMDNORwdRqVSZgWBkjAUN5NqAqBgYm ZAAWAYliAgD0TyTkCmVuZHN0cmVhbQplbmRvYmoKMzYgMCBvYmoKMTA1CmVuZG9iago0MyAwIG9i ago8PCAvTGVuZ3RoIDQ0IDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGFVM9rE0EU/jZuqdAiCFprDrJ4kCJJWatoRdQ2/RFiawzb H7ZFkGQzSdZuNuvuJrWliOTi0SreRe2hB/+AHnrwZC9KhVpFKN6rKGKhFy3xzW5MtqXqwM5+8943 731vdt8ADXLSNPWABOQNx1KiEWlsfEJq/IgAjqIJQTQlVdvsTiQGQYNz+Xvn2HoPgVtWw3v7d7J3 rZrStpoHhP1A4Eea2Sqw7xdxClkSAog836Epx3QI3+PY8uyPOU55eMG1Dys9xFkifEA1Lc5/TbhT zSXTQINIOJT1cVI+nNeLlNcdB2luZsbIEL1PkKa7zO6rYqGcTvYOkL2d9H5Os94+wiHCCxmtP0a4 jZ71jNU/4mHhpObEhj0cGDX0+GAVtxqp+DXCFF8QTSeiVHHZLg3xmK79VvJKgnCQOMpkYYBzWkhP 10xu+LqHBX0m1xOv4ndWUeF5jxNn3tTd70XaAq8wDh0MGgyaDUhQEEUEYZiwUECGPBoxNLJyPyOr BhuTezJ1JGq7dGJEsUF7Ntw9t1Gk3Tz+KCJxlEO1CJL8Qf4qr8lP5Xn5y1yw2Fb3lK2bmrry4DvF 5Zm5Gh7X08jjc01efJXUdpNXR5aseXq8muwaP+xXlzHmgjWPxHOw+/EtX5XMlymMFMXjVfPqS4R1 WjE3359sfzs94i7PLrXWc62JizdWm5dn/WpI++6qvJPmVflPXvXx/GfNxGPiKTEmdornIYmXxS7x kthLqwviYG3HCJ2VhinSbZH6JNVgYJq89S9dP1t4vUZ/DPVRlBnM0lSJ93/CKmQ0nbkOb/qP28f8 F+T3iuefKAIvbODImbptU3HvEKFlpW5zrgIXv9F98LZua6N+OPwEWDyrFq1SNZ8gvAEcdod6Hugp mNOWls05Uocsn5O66cpiUsxQ20NSUtcl12VLFrOZVWLpdtiZ0x1uHKE5QvfEp0plk/qv8RGw/bBS +fmsUtl+ThrWgZf6b8C8/UUKZW5kc3RyZWFtCmVuZG9iago0NCAwIG9iago3MzcKZW5kb2JqCjM0 IDAgb2JqClsgL0lDQ0Jhc2VkIDQzIDAgUiBdCmVuZG9iago0NSAwIG9iago8PCAvTGVuZ3RoIDQ2 IDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pgpz dHJlYW0KeAGdlndUFNcXx9/MbC+0XZYiZem9twWkLr1IlSYKy+4CS1nWZRewN0QFIoqICFYkKGLA aCgSK6JYCAgW7AEJIkoMRhEVlczGHPX3Oyf5/U7eH3c+8333nnfn3vvOGQAoASECYQ6sAEC2UCKO 9PdmxsUnMPG9AAZEgAM2AHC4uaLQKL9ogK5AXzYzF3WS8V8LAuD1LYBaAK5bBIQzmX/p/+9DkSsS SwCAwtEAOx4/l4tyIcpZ+RKRTJ9EmZ6SKWMYI2MxmiDKqjJO+8Tmf/p8Yk8Z87KFPNRHlrOIl82T cRfKG/OkfJSREJSL8gT8fJRvoKyfJc0WoPwGZXo2n5MLAIYi0yV8bjrK1ihTxNGRbJTnAkCgpH3F KV+xhF+A5gkAO0e0RCxIS5cwjbkmTBtnZxYzgJ+fxZdILMI53EyOmMdk52SLOMIlAHz6ZlkUUJLV lokW2dHG2dHRwtYSLf/n9Y+bn73+GWS9/eTxMuLPnkGMni/al9gvWk4tAKwptDZbvmgpOwFoWw+A 6t0vmv4+AOQLAWjt++p7GLJ5SZdIRC5WVvn5+ZYCPtdSVtDP6386fPb8e/jqPEvZeZ9rx/Thp3Kk WRKmrKjcnKwcqZiZK+Jw+UyL/x7ifx34VVpf5WEeyU/li/lC9KgYdMoEwjS03UKeQCLIETIFwr/r 8L8M+yoHGX6aaxRodR8BPckSKPTRAfJrD8DQyABJ3IPuQJ/7FkKMAbKbF6s99mnuUUb3/7T/YeAy 9BXOFaQxZTI7MprJlYrzZIzeCZnBAhKQB3SgBrSAHjAGFsAWOAFX4Al8QRAIA9EgHiwCXJAOsoEY 5IPlYA0oAiVgC9gOqsFeUAcaQBM4BtrASXAOXARXwTVwE9wDQ2AUPAOT4DWYgSAID1EhGqQGaUMG kBlkC7Egd8gXCoEioXgoGUqDhJAUWg6tg0qgcqga2g81QN9DJ6Bz0GWoH7oDDUPj0O/QOxiBKTAd 1oQNYSuYBXvBwXA0vBBOgxfDS+FCeDNcBdfCR+BW+Bx8Fb4JD8HP4CkEIGSEgeggFggLYSNhSAKS ioiRlUgxUonUIk1IB9KNXEeGkAnkLQaHoWGYGAuMKyYAMx/DxSzGrMSUYqoxhzCtmC7MdcwwZhLz EUvFamDNsC7YQGwcNg2bjy3CVmLrsS3YC9ib2FHsaxwOx8AZ4ZxwAbh4XAZuGa4UtxvXjDuL68eN 4KbweLwa3gzvhg/Dc/ASfBF+J/4I/gx+AD+Kf0MgE7QJtgQ/QgJBSFhLqCQcJpwmDBDGCDNEBaIB 0YUYRuQRlxDLiHXEDmIfcZQ4Q1IkGZHcSNGkDNIaUhWpiXSBdJ/0kkwm65KdyRFkAXk1uYp8lHyJ PEx+S1GimFLYlESKlLKZcpBylnKH8pJKpRpSPakJVAl1M7WBep76kPpGjiZnKRcox5NbJVcj1yo3 IPdcnihvIO8lv0h+qXyl/HH5PvkJBaKCoQJbgaOwUqFG4YTCoMKUIk3RRjFMMVuxVPGw4mXFJ0p4 JUMlXyWeUqHSAaXzSiM0hKZHY9O4tHW0OtoF2igdRzeiB9Iz6CX07+i99EllJWV75RjlAuUa5VPK QwyEYcgIZGQxyhjHGLcY71Q0VbxU+CqbVJpUBlSmVeeoeqryVYtVm1Vvqr5TY6r5qmWqbVVrU3ug jlE3VY9Qz1ffo35BfWIOfY7rHO6c4jnH5tzVgDVMNSI1lmkc0OjRmNLU0vTXFGnu1DyvOaHF0PLU ytCq0DqtNa5N03bXFmhXaJ/RfspUZnoxs5hVzC7mpI6GToCOVGe/Tq/OjK6R7nzdtbrNug/0SHos vVS9Cr1OvUl9bf1Q/eX6jfp3DYgGLIN0gx0G3QbThkaGsYYbDNsMnxipGgUaLTVqNLpvTDX2MF5s XGt8wwRnwjLJNNltcs0UNnUwTTetMe0zg80czQRmu836zbHmzuZC81rzQQuKhZdFnkWjxbAlwzLE cq1lm+VzK32rBKutVt1WH60drLOs66zv2SjZBNmstemw+d3W1JZrW2N7w45q52e3yq7d7oW9mT3f fo/9bQeaQ6jDBodOhw+OTo5ixybHcSd9p2SnXU6DLDornFXKuuSMdfZ2XuV80vmti6OLxOWYy2+u Fq6Zroddn8w1msufWzd3xE3XjeO2323Ineme7L7PfchDx4PjUevxyFPPk+dZ7znmZeKV4XXE67m3 tbfYu8V7mu3CXsE+64P4+PsU+/T6KvnO9632fein65fm1+g36e/gv8z/bAA2IDhga8BgoGYgN7Ah cDLIKWhFUFcwJTgquDr4UYhpiDikIxQODQrdFnp/nsE84by2MBAWGLYt7EG4Ufji8B8jcBHhETUR jyNtIpdHdkfRopKiDke9jvaOLou+N994vnR+Z4x8TGJMQ8x0rE9seexQnFXcirir8erxgvj2BHxC TEJ9wtQC3wXbF4wmOiQWJd5aaLSwYOHlReqLshadSpJP4iQdT8YmxyYfTn7PCePUcqZSAlN2pUxy 2dwd3Gc8T14Fb5zvxi/nj6W6pZanPklzS9uWNp7ukV6ZPiFgC6oFLzICMvZmTGeGZR7MnM2KzWrO JmQnZ58QKgkzhV05WjkFOf0iM1GRaGixy+LtiyfFweL6XCh3YW67hI7+TPVIjaXrpcN57nk1eW/y Y/KPFygWCAt6lpgu2bRkbKnf0m+XYZZxl3Uu11m+ZvnwCq8V+1dCK1NWdq7SW1W4anS1/+pDa0hr Mtf8tNZ6bfnaV+ti13UUahauLhxZ77++sUiuSFw0uMF1w96NmI2Cjb2b7Dbt3PSxmFd8pcS6pLLk fSm39Mo3Nt9UfTO7OXVzb5lj2Z4tuC3CLbe2emw9VK5YvrR8ZFvottYKZkVxxavtSdsvV9pX7t1B 2iHdMVQVUtW+U3/nlp3vq9Orb9Z41zTv0ti1adf0bt7ugT2ee5r2au4t2ftun2Df7f3++1trDWsr D+AO5B14XBdT1/0t69uGevX6kvoPB4UHhw5FHupqcGpoOKxxuKwRbpQ2jh9JPHLtO5/v2pssmvY3 M5pLjoKj0qNPv0/+/tax4GOdx1nHm34w+GFXC62luBVqXdI62ZbeNtQe395/IuhEZ4drR8uPlj8e PKlzsuaU8qmy06TThadnzyw9M3VWdHbiXNq5kc6kznvn487f6Iro6r0QfOHSRb+L57u9us9ccrt0 8rLL5RNXWFfarjpebe1x6Gn5yeGnll7H3tY+p772a87XOvrn9p8e8Bg4d93n+sUbgTeu3px3s//W /Fu3BxMHh27zbj+5k3Xnxd28uzP3Vt/H3i9+oPCg8qHGw9qfTX5uHnIcOjXsM9zzKOrRvRHuyLNf cn95P1r4mPq4ckx7rOGJ7ZOT437j154ueDr6TPRsZqLoV8Vfdz03fv7Db56/9UzGTY6+EL+Y/b30 pdrLg6/sX3VOhU89fJ39ema6+I3am0NvWW+738W+G5vJf49/X/XB5EPHx+CP92ezZ2f/AAOY8/wK ZW5kc3RyZWFtCmVuZG9iago0NiAwIG9iagoyNjE1CmVuZG9iago3IDAgb2JqClsgL0lDQ0Jhc2Vk IDQ1IDAgUiBdCmVuZG9iago0OCAwIG9iago8PCAvTGVuZ3RoIDQ5IDAgUiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PgpzdHJlYW0KeAHNWkmX3LYRvvNX4JC8cN6zKAIguOSmWHKWZ8WyPIoPUQ7KaMZZ LFnqHju2f2F+Vr5CoQoA2d3TGvkQ+42bJgu1rwDemy/Ne2Nn40PfjYMJ02gG5zs/mt21+dq8NQ8/ 3VtztTc2/ru/Ogbc3Bz7Ym4McPd+cXY8+MRIrV/mbhlNGGw3DAAEL/2wzA0YAW4h75YuODMMobP9 AJJ95+bZuND5wS8LcX1jXL90cz8XUFM3QTKBYpR+mbowDwo1jN0Yxt4qWELGBL0FIaVnfTe7obeM SekJEJMTIMaj5BhIqQlUQhWpTePcuSxd6KAKMBaF67sZyuE/aI71sVpAygvLPG+UlxQj4DD6Yp05 if/wkmMU/Nh3kzOJgB+7eYSaTlI4suQohWS2REL1eEoI0f16zTEaSalD3/XwWXUyGAVWOWGF1YKj 6EWnAp/s4E4QOLLkGAlRaqKghjhB4tiSoyTEEImGWuIUjWNrjhFJlrAOKQlZCnHRI025CclqlohQ 6yaozEgCK0NrmHqkF+QGO5CjOmSbxZ2w6Qr+NJ/DZLseLlIg98hlyWMc4pb/ELfvOcOZHv8+IKzk Z8aGfqLM0ly9Mb+7NIjN+B2/3jkA4D+Xb8zDz1zXIyFe3pjWXJjLf5knlzGRM55zUQYfCOXEKME5 o/yraV9dEE/OtG8vIs/tXl78J75o2mt5sZMHffMab4Kn1eANObN9n5B8n34VMmFt2tt/pk/fpV/Q /Zu5/NM5chlWFUK1711ziQKVlTZZ1I2thK1z99eac6S1MP6ShhhKlKUhVO//FjWLpt5FTTUt/5ps kKj+oRvOVr8R9Tft/dVfKZ3qZBib6KkqTdufq/Nk0QIlVV5vYV3yfcUIR4Ww0U/VC9Vzb26hMeQJ +N+DqDtv2p//kcBfXTS1f3+zBf5BND7Kg2hHVE7GcWM3NZnClcACoQTQg4DmpOBCbSr4JC52wpVi oUgJA4WSynC7FbUE16hpTieYrY6DQ/xDydtsMAtfg0jXJelUNb/Glxl9mzrdy9YKsD68vEBUN/eI alNH9dgv4LQP7A45FdrQDWDkvHS4VcDoCK1dVmjhZS9b5At2mCjD+ZmpQRLnzLSSIWYm1XYhgz9X gG2JCBZpxIdhlZkgwKfCPlyO5XjzRrPwWzEvIib6LDno7IoELh9oNT4gpFJmlw+IK0Z7DVwUEgpx pZ80MpHBGHgHQuqvVOi64CcXhoWehtAvs23urJRbO4ZhghrQLVSVsoEa/iCUlQVKllFm0gYYz6I9 L7+wWhD3BBzTJK9CmeKHvWqzlglKpLX0d6ckW4NO1BH4EYW+rvnwRnHy9Vy0akCcowaf+x8MYWCE /3RwGJc47KWGJfYPNHRxy5JmrRonwRSzRQ3DH5fZG8ekGdEw+G5E3yb9EdOxi4IxhyqMR8xgFBzD 0i007WFGCtT++W7oJ3yIDRXNi+jOx8nH4W5AEKGvQw84Tioxqd7Os/PBw8EgtSyaQzej/UuLVKZT mBWImRVMiXwWiTlIgvulG71TJhVHxSfN4IRuwtg9TkPnSWbMeJDUWoy7aGwIXTmOw5B2GaEMCOjp YR4aKG2M/0x3O1sKm4O5aRwRQMPQb8vti3ff7F69jrGSQ/y/ZRQf204gnZX8Z1MPUzfAEmpGtmap RHFa+t1fNV5WiA15RVYte4dAiXtsobBlobgKK0bnTvYRfwDpgsdMStkErmjFAQMKvFCtCG90tC9x 3I4flSECHIBMtcoQyHWfS2rSzKQJeEcZH3shi2bpp1oXdgDPOfmYNUtvbLA5xPsR2LQ52/HK5o68 DaPI5Zumbu5+n+rRF+kXIsVE/Bii0Yyp7H+WPjx5JEJfXiAaAPBCXmg6f/LbcnUWVdL0PVO1peaB pVi1qJeJObXDj8ITqid1qCgoqZwq+zJ2qcm+TUh+krVUo6OEMg/QC0xdQZFt1goO2Dqu5FHOxNmu Kn2JSB4H0KCmJlbqPvkLRiBhXHtl4UaFBRFqDBdl62aHN5G+whydD0UNt8I6cUYNiGKT1lnVoUip sgM0KI8iroif+Gh0hogajK16klI1KHwQTm7mE4RMAmhyIFLTqmy6dMuYvvmkjLTT3fq2NcDUjrhf OO7LiUiHAWXhVnXCQ0m2q7IrZvuZQOFFOTMoiCJR/t+lGBOFipYUoFoyW7WEciYrXiMfVXq9Fbsq eYCWDic0xQBKKqa2euorvrHjw4y1A7JdlT9RWNNWoRqyL4m+RIBbigdsfCoKIZFExQ4HPSHYMQgm 39FQFlk2UbY1ZZSubK9VPyqkKldiRn6JHiUIZeD7ZL+tvbrzPXPbfg8jphC45naMSoJLQiSdzeU+ ESkgGiZ205h7hdemlTUq5o9Injl5n46eLY8xeka/ZfER+VnkodQjv/lpD7MnBhG7lNaywaFM/pSG BNPSlkLEtFNU5GfqeXRyobaANPF/o07KBLdxmwNFkXE+JpbQ7itO9smUleB6ok3TPvtcGHkkiv1j YuDP8uWFPDzFA1UpwtvQdp5KCM9i0iqgaq/yIDmtoF9qwVNzP9AmlbT22lLJrOL0wGj7dOcoxRZv 1k3GnPKljtvok77SATXpy7RUs6I11N46IpNRYThW8v39b6LsPacQ0exNuwwy132oR+McK2Ms5UtB Jw5WBRDtLWUXptaP5d4nE3/ApHsnv7QTUthjxPEcMbxtXNUDyR6oCjlIhMGmFQYN7Vgyz+p61Sj+ IJQRkT8l1y32sa82GkK0ZgvH5p4dl4ZYnJKmmdROtCGyu24OTzenluCk8jTa9dB0JJAsygoCUzjS UOLh5UNJfMA8ciCxogsOdt4m1jxh7KHoehdJbUjVrEpUuk+rqYYesLsgRVSX3jDSnOPEnBrem60p zVqaqTUA1Jk0YxPwhN2IRBkuqIiVB61fyi0tR83N26J/xwutAFLhYlZVSsqEvtE0dKUsi3QVMPEX O+PstneG5eqUydE8CQPyMFbmEaFI0lZ7gF8XpSuKtqvFD8VMIlXm2Q+0c1y1549FMypjbFiyQdP7 poWpIx3hSHVA7gOc0LbulisyDW9V5ndSscnYVS2XPFOUOrXxTqjuuyI90LD58fWqzI80TgY/bANJ t9wfJjVMojh5ofvt9ADvkwTatLoWM3BUIQoOu6N+eUTlHou4LGRHWu/OWjuN4T67s5Z6L0hWJ37a nf2LmkYtSpUYFs016rkwrCCbUtDQoWWqYxmqMNYdSffw3obet0jdS1igQEzA/zdJF9aod4mhUfV+ jch9Ct+cQbdZZn+lzeyeZgMYQFwIR4XJczT7kYqrHX+J8a++iKBNPHyopjs9jXjCIKb9DYFiQCRy YS524X8lpgz80LTq7ot8+iSx1MuL6gFJMQurCtGGTn1Fk7fCkNLQ6+Vdjn31KQZQeoPJH9mqiJaP SwcHxn1KBxihNybWwJXoX71o6nO4Ih2YdhaFSTrw8kLzwrMyHTSFgLBXeVgT08F9Nv84HeCgZyPZ vdNBGsTI06ON1MS5/YOfZVmoQRqwTT+bqccJIoIaWqLjBsx3bu7dtG7DdO864MQTfezU4+YYfnGL x1KLKwck3H/h7YwTAALq8Ys1DichBFRcb4Obaf3YPmHeWWHh5XQuoIioB8U9uZ4ODJQa87KUBJmr LAPnMRUd9TNe06sOec5hj7KhYKnZ4w31xB56ChxrrABZHwKX+uITtxKbza1ENiCdZi04RIkGnNK2 u13kxOiAGKjcom9oucaSlUe79xmN7eMZkxFqWzgeYlXHGW3JGytJD9vIV+XvzgE3ZYjDxzc4x8cx GeeKPFw+v96/++7t/hq+f96Quc1Clq6+HECNGVNQ4nIVpOC/c6UoxkJLNz2UQtl/Hj2Dp/DFVdBu wQ0qcStEy4hboXcGsEVQTrhGKhGMMyOHGwDxAJoPOVO0AI5YkyDGKY/HxK0WlE0LcaXsVPkJ2iBy JZrsOCtMaJCiHws9/gxGFW4VxRaZK8S45wwGjwvwNSag90AzM4eeIoM1moquhCdlGRpdYDbR90G4 +4SxGFJCSwxZxd8B5uswXmNhNVAWXAUy2pIefiLUVAwBW8VxiZciGYxgNa9axXF16Hx6CktxhmJF N9hW90QssmoOCI1mNHeX17QHinlZh+FHb199i03K/UVRqGN0BGwQ4JKjWGtk55LoIFc6uHlhcfwe jczlDTd7cbLJulSXQleCuxocQVTeRuyN4Gejk9OR0azRqCVWiJxFodYwPAhF7imXxS0kX4rCPmKW SHEr3gwvPeBP+R3NOGs0Fd0CkXPoAIo0RHD8WZ/Yo6JVPujSfTKheGo0YSgK3LkZaIVH+SojAxok SSbkE6GnEktkrPNPgReRoezxOr3Fz/XtA2LjwA4T3e5BheCGsQyIp7RhgO2jHBA6aGjjLkc7cXue uMEGIp8U0+ZBfIEpNP4enh3PCuWioHl/uBr/ciXTe19kiLpk6iRUX1v78n9n/AMpCmVuZHN0cmVh bQplbmRvYmoKNDkgMCBvYmoKMzMzNgplbmRvYmoKNDcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1Bh cmVudCAzIDAgUiAvUmVzb3VyY2VzIDUwIDAgUiAvQ29udGVudHMgNDggMCBSIC9NZWRpYUJveApb MCAwIDYxMiA3OTJdIC9Bbm5vdHMgNTEgMCBSID4+CmVuZG9iago1MCAwIG9iago8PCAvUHJvY1Nl dCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9G Mi4wIDE3IDAgUgovRjEuMCAxMCAwIFIgPj4gPj4KZW5kb2JqCjUxIDAgb2JqClsgNTIgMCBSIDUz IDAgUiA1NCAwIFIgNTUgMCBSIDU2IDAgUiA1NyAwIFIgNTggMCBSIDU5IDAgUiBdCmVuZG9iagoz IDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXSAvQ291bnQgMiAv S2lkcyBbIDIgMCBSIDQ3IDAgUiBdID4+CmVuZG9iago2MCAwIG9iago8PCAvVHlwZSAvQ2F0YWxv ZyAvUGFnZXMgMyAwIFIgL1ZlcnNpb24gLzEuNCA+PgplbmRvYmoKNTkgMCBvYmoKPDwgL1N1YnR5 cGUgL0xpbmsgL0EgNjEgMCBSIC9SZWN0IFsxNTcuMzkyIDY5My4zNiAyMjEuMzI4IDcwNy4xODRd IC9UeXBlIC9Bbm5vdAovQm9yZGVyIFsgMCAwIDAgXSA+PgplbmRvYmoKNjEgMCBvYmoKPDwgL1VS SSA2MiAwIFIgL1R5cGUgL0FjdGlvbiAvUyAvVVJJID4+CmVuZG9iago2MiAwIG9iagooaHR0cDov L3d3dy5zdXJ2ZXltb25rZXkuY29tL015U3VydmV5X1Jlc3BvbnNlcy5hc3B4P3NtPVZTT2lQRnNp WThkc1FoZEY3Y0F1cUJBRWFyWkxua3glMmJZZ1hJV0pGRXR4ZyUzZCMpCmVuZG9iago1OCAwIG9i ago8PCAvU3VidHlwZSAvTGluayAvQSA2MyAwIFIgL1JlY3QgWzEwNC45NzYgNjkzLjM2IDE1NS42 NjQgNzA3LjE4NF0gL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWyAwIDAgMCBdID4+CmVuZG9iago2MyAw IG9iago8PCAvVVJJIDY0IDAgUiAvVHlwZSAvQWN0aW9uIC9TIC9VUkkgPj4KZW5kb2JqCjY0IDAg b2JqCihodHRwOi8vd3d3LnN1cnZleW1vbmtleS5jb20vTXlTdXJ2ZXlfUmVzcG9uc2VzLmFzcHg/ c209VlNPaVBGc2lZOGRzUWhkRjdjQXVxQkFFYXJaTG5reCUyYllnWElXSkZFdHhnJTNkIykKZW5k b2JqCjU3IDAgb2JqCjw8IC9TdWJ0eXBlIC9MaW5rIC9BIDY1IDAgUiAvUmVjdCBbNDkuNjggNjkz LjM2IDEwMy4yNDggNzA3LjE4NF0gL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWyAwIDAgMCBdID4+CmVu ZG9iago2NSAwIG9iago8PCAvVVJJIDY2IDAgUiAvVHlwZSAvQWN0aW9uIC9TIC9VUkkgPj4KZW5k b2JqCjY2IDAgb2JqCihodHRwOi8vd3d3LnN1cnZleW1vbmtleS5jb20vTXlTdXJ2ZXlfUmVzcG9u c2VzLmFzcHg/c209VlNPaVBGc2lZOGRzUWhkRjdjQXVxQkFFYXJaTG5reCUyYllnWElXSkZFdHhn JTNkIykKZW5kb2JqCjU2IDAgb2JqCjw8IC9TdWJ0eXBlIC9MaW5rIC9BIDY3IDAgUiAvUmVjdCBb OTEuMTUyIDU5NS40NCAxNDMuNTY4IDYwMy41MDRdIC9UeXBlIC9Bbm5vdAovQm9yZGVyIFsgMCAw IDAgXSA+PgplbmRvYmoKNjcgMCBvYmoKPDwgL1VSSSA2OCAwIFIgL1R5cGUgL0FjdGlvbiAvUyAv VVJJID4+CmVuZG9iago2OCAwIG9iagooaHR0cDovL3d3dy5zdXJ2ZXltb25rZXkuY29tL015U3Vy dmV5X1Jlc3BvbnNlc0RldGFpbC5hc3B4P3NtPVZTT2lQRnNpWThkc1FoZEY3Y0F1cUpOcE1hZGg2 QUlBSnNGRXJvSmhRYmF2bnAxMzNQTGY3NmVpUTJsNkFXb2VJcXNNaEY4Q05uT3dfMEFGcE5KU2Z4 T1FRXzNEXzNEXzBBKQplbmRvYmoKNTUgMCBvYmoKPDwgL1N1YnR5cGUgL0xpbmsgL0EgNjkgMCBS IC9SZWN0IFs5MS4xNTIgNjIyLjUxMiAxNDMuNTY4IDYzMC41NzZdIC9UeXBlIC9Bbm5vdAovQm9y ZGVyIFsgMCAwIDAgXSA+PgplbmRvYmoKNjkgMCBvYmoKPDwgL1VSSSA3MCAwIFIgL1R5cGUgL0Fj dGlvbiAvUyAvVVJJID4+CmVuZG9iago3MCAwIG9iagooaHR0cDovL3d3dy5zdXJ2ZXltb25rZXku Y29tL015U3VydmV5X1Jlc3BvbnNlc0RldGFpbC5hc3B4P3NtPVZTT2lQRnNpWThkc1FoZEY3Y0F1 cUpOcE1hZGg2QUlBSnNGRXJvSmhRYmF2bnAxMzNQTGY3NmVpUTJsNkFXb2VKVk5RdFlWblBheWJf MEEvekdTaFhVTWRRXzNEXzNEXzBBKQplbmRvYmoKNTQgMCBvYmoKPDwgL1N1YnR5cGUgL0xpbmsg L0EgNzEgMCBSIC9SZWN0IFszNDcuNDcyIDY3My43NzYgMzkxLjI0OCA2ODYuNDQ4XSAvVHlwZQov QW5ub3QgL0JvcmRlciBbIDAgMCAwIF0gPj4KZW5kb2JqCjcxIDAgb2JqCjw8IC9VUkkgNzIgMCBS IC9UeXBlIC9BY3Rpb24gL1MgL1VSSSA+PgplbmRvYmoKNzIgMCBvYmoKKGh0dHA6Ly93d3cuc3Vy dmV5bW9ua2V5LmNvbS9NeVN1cnZleV9SZXNwb25zZXMuYXNweD9zbT1WU09pUEZzaVk4ZHNRaGRG N2NBdXFCQUVhclpMbmt4JTJiWWdYSVdKRkV0eGclM2QjKQplbmRvYmoKNTMgMCBvYmoKPDwgL1N1 YnR5cGUgL0xpbmsgL0EgNzMgMCBSIC9SZWN0IFszOTguMTYgNjczLjc3NiA0NDAuMjA4IDY4Ni40 NDhdIC9UeXBlIC9Bbm5vdAovQm9yZGVyIFsgMCAwIDAgXSA+PgplbmRvYmoKNzMgMCBvYmoKPDwg L1VSSSA3NCAwIFIgL1R5cGUgL0FjdGlvbiAvUyAvVVJJID4+CmVuZG9iago3NCAwIG9iagooaHR0 cDovL3d3dy5zdXJ2ZXltb25rZXkuY29tL3ByaWNpbmcvdXBncmFkZT91dG1fc291cmNlPXRleHRf YW5hbHlzaXNfdG9wYmFyKQplbmRvYmoKNTIgMCBvYmoKPDwgL1N1YnR5cGUgL0xpbmsgL0EgNzUg MCBSIC9SZWN0IFszMzMuMDcyIDcxOC4xMjggMzg0LjMzNiA3MjYuMTkyXSAvVHlwZQovQW5ub3Qg L0JvcmRlciBbIDAgMCAwIF0gPj4KZW5kb2JqCjc1IDAgb2JqCjw8IC9VUkkgNzYgMCBSIC9UeXBl IC9BY3Rpb24gL1MgL1VSSSA+PgplbmRvYmoKNzYgMCBvYmoKKGh0dHA6Ly93d3cuc3VydmV5bW9u a2V5LmNvbS9NeVN1cnZleV9SZXNwb25zZXMuYXNweD9zbT1WU09pUEZzaVk4ZHNRaGRGN2NBdXFC QUVhclpMbmt4JTJiWWdYSVdKRkV0eGclM2QjKQplbmRvYmoKMzEgMCBvYmoKPDwgL1N1YnR5cGUg L0xpbmsgL0EgNzcgMCBSIC9SZWN0IFsxMDMuODI0IDY0MC4zNjggMTYwLjg0OCA2NTMuMDRdIC9U eXBlIC9Bbm5vdAovQm9yZGVyIFsgMCAwIDAgXSA+PgplbmRvYmoKNzcgMCBvYmoKPDwgL1VSSSA3 OCAwIFIgL1R5cGUgL0FjdGlvbiAvUyAvVVJJID4+CmVuZG9iago3OCAwIG9iagooaHR0cDovL3d3 dy5zdXJ2ZXltb25rZXkuY29tL3dlYmNvbnRyb2xzLyMpCmVuZG9iagozMCAwIG9iago8PCAvU3Vi dHlwZSAvTGluayAvQSA3OSAwIFIgL1JlY3QgWzE4OS42NDggNjY5LjE2OCAyMDEuNzQ0IDY3Ny4y MzIxXSAvVHlwZQovQW5ub3QgL0JvcmRlciBbIDAgMCAwIF0gPj4KZW5kb2JqCjc5IDAgb2JqCjw8 IC9VUkkgODAgMCBSIC9UeXBlIC9BY3Rpb24gL1MgL1VSSSA+PgplbmRvYmoKODAgMCBvYmoKKGh0 dHA6Ly93d3cuc3VydmV5bW9ua2V5LmNvbS9NeVN1cnZleV9TZXR0aW5nc1RpdGxlLmFzcHg/c209 VlNPaVBGc2lZOGRzUWhkRjdjQXVxQkFFYXJaTG5reCUyYllnWElXSkZFdHhnJTNkJlRCX2lmcmFt ZT10cnVlJmhlaWdodD0yMDAmd2lkdGg9NDAwKQplbmRvYmoKMjkgMCBvYmoKPDwgL1N1YnR5cGUg L0xpbmsgL0EgODEgMCBSIC9SZWN0IFsxOS4xNTIgNjY4LjU5MiAxODYuMTkyIDY4MS4yNjRdIC9U eXBlIC9Bbm5vdAovQm9yZGVyIFsgMCAwIDAgXSA+PgplbmRvYmoKODEgMCBvYmoKPDwgL1VSSSA4 MiAwIFIgL1R5cGUgL0FjdGlvbiAvUyAvVVJJID4+CmVuZG9iago4MiAwIG9iagooaHR0cDovL3d3 dy5zdXJ2ZXltb25rZXkuY29tL015U3VydmV5X1NldHRpbmdzVGl0bGUuYXNweD9zbT1WU09pUEZz aVk4ZHNRaGRGN2NBdXFCQUVhclpMbmt4JTJiWWdYSVdKRkV0eGclM2QmVEJfaWZyYW1lPXRydWUm aGVpZ2h0PTIwMCZ3aWR0aD00MDApCmVuZG9iagoyOCAwIG9iago8PCAvU3VidHlwZSAvTGluayAv QSA4MyAwIFIgL1JlY3QgWzQ0NS4zOTIgNzExLjIxNiA0OTAuODk2IDcxOS4yOF0gL1R5cGUgL0Fu bm90Ci9Cb3JkZXIgWyAwIDAgMCBdID4+CmVuZG9iago4MyAwIG9iago8PCAvVVJJIDg0IDAgUiAv VHlwZSAvQWN0aW9uIC9TIC9VUkkgPj4KZW5kb2JqCjg0IDAgb2JqCihodHRwczovL3d3dy5zdXJ2 ZXltb25rZXkuY29tL3ByaWNpbmcvP3V0bV9zb3VyY2U9YWNjb3VudF90b3BiYXIpCmVuZG9iagox NiAwIG9iago8PCAvU3VidHlwZSAvTGluayAvQSA4NSAwIFIgL1JlY3QgWzMzMS4zNDQgNTc2LjQz MiAzOTAuNjcyIDU4NS42NDhdIC9UeXBlCi9Bbm5vdCAvQm9yZGVyIFsgMCAwIDAgXSA+PgplbmRv YmoKODUgMCBvYmoKPDwgL1VSSSA4NiAwIFIgL1R5cGUgL0FjdGlvbiAvUyAvVVJJID4+CmVuZG9i ago4NiAwIG9iagooaHR0cDovL3d3dy5zdXJ2ZXltb25rZXkuY29tL015U3VydmV5X0NoYXJ0QnVp bGRlci5hc3B4P3NtPVdCd1kzQ3pmOGkxdTlmJTJmRFFkWXU2eEtoaHFIQjgyNkVHU0RVTHQ3UnZj cmZRbmMlMmZWeURwTDJCQTglMmZSV1clMmZndkg4em4zb0FVY0dIUlklMmJTWFhKbGE1NlN5c3hQ OWhYWHpsNnlFNmVIYWJaZyUzZCZUQl9pZnJhbWU9dHJ1ZSZ3aWR0aD04MDUmaGVpZ2h0PTYyOCkK ZW5kb2JqCjE1IDAgb2JqCjw8IC9TdWJ0eXBlIC9MaW5rIC9BIDg3IDAgUiAvUmVjdCBbMzkwLjY3 MiA1NzYuNDMyIDQzNS42IDU4NS42NDhdIC9UeXBlIC9Bbm5vdAovQm9yZGVyIFsgMCAwIDAgXSA+ PgplbmRvYmoKODcgMCBvYmoKPDwgL1VSSSA4OCAwIFIgL1R5cGUgL0FjdGlvbiAvUyAvVVJJID4+ CmVuZG9iago4OCAwIG9iagooaHR0cDovL3d3dy5zdXJ2ZXltb25rZXkuY29tL015U3VydmV5X1F1 ZXN0aW9uRXhwb3J0LmFzcHg/c209VlNPaVBGc2lZOGRzUWhkRjdjQXVxTGp2QmhHMFcwYXJTemVz SllRS2ZDMUwwS1I1T3k1ZmtyV0pNJTJmOEtnZHFhTkxvYkN3U1pBZjZDVGxndnpuNTc2SFdpNFVU WkhRY0VyYU5jTmZrWG02OCUzZCZUQl9pZnJhbWU9dHJ1ZSZ3aWR0aD01NDAmaGVpZ2h0PTQ3MCkK ZW5kb2JqCjE0IDAgb2JqCjw8IC9TdWJ0eXBlIC9MaW5rIC9BIDg5IDAgUiAvUmVjdCBbMjIyLjQ4 IDczMC44IDI4Mi45NiA3NDAuMDE2XSAvVHlwZSAvQW5ub3QKL0JvcmRlciBbIDAgMCAwIF0gPj4K ZW5kb2JqCjg5IDAgb2JqCjw8IC9VUkkgOTAgMCBSIC9UeXBlIC9BY3Rpb24gL1MgL1VSSSA+Pgpl bmRvYmoKOTAgMCBvYmoKKGh0dHA6Ly93d3cuc3VydmV5bW9ua2V5LmNvbS9wcmljaW5nL3VwZ3Jh ZGUvcXVpY2t2aWV3P3V0bV9zb3VyY2U9aGVhZGVyX2xvZ2dlZEluKQplbmRvYmoKMTMgMCBvYmoK PDwgL1N1YnR5cGUgL0xpbmsgL0EgOTEgMCBSIC9SZWN0IFsxNTkuMTIgNzMwLjggMjA1LjIgNzQw LjAxNl0gL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWyAwIDAgMCBdID4+CmVuZG9iago5MSAwIG9iago8 PCAvVVJJIDkyIDAgUiAvVHlwZSAvQWN0aW9uIC9TIC9VUkkgPj4KZW5kb2JqCjkyIDAgb2JqCiho dHRwczovL3d3dy5zdXJ2ZXltb25rZXkuY29tL015QWNjb3VudC5hc3B4KQplbmRvYmoKMTIgMCBv YmoKPDwgL1N1YnR5cGUgL0xpbmsgL0EgOTMgMCBSIC9SZWN0IFs4Ni41NDQgNzMwLjggMTQxLjg0 IDc0MC4wMTZdIC9UeXBlIC9Bbm5vdAovQm9yZGVyIFsgMCAwIDAgXSA+PgplbmRvYmoKOTMgMCBv YmoKPDwgL1VSSSA5NCAwIFIgL1R5cGUgL0FjdGlvbiAvUyAvVVJJID4+CmVuZG9iago5NCAwIG9i agooaHR0cDovL3d3dy5zdXJ2ZXltb25rZXkuY29tL0FkZHJlc3NCb29rX0xpc3RTdW1tYXJ5LmFz cHgpCmVuZG9iagoxMSAwIG9iago8PCAvU3VidHlwZSAvTGluayAvQSA5NSAwIFIgL1JlY3QgWzIz Ljc2IDczMC44IDY5LjI2NCA3NDAuMDE2XSAvVHlwZSAvQW5ub3QKL0JvcmRlciBbIDAgMCAwIF0g Pj4KZW5kb2JqCjk1IDAgb2JqCjw8IC9VUkkgOTYgMCBSIC9UeXBlIC9BY3Rpb24gL1MgL1VSSSA+ PgplbmRvYmoKOTYgMCBvYmoKKGh0dHA6Ly93d3cuc3VydmV5bW9ua2V5LmNvbS9NeVN1cnZleXMu YXNweCkKZW5kb2JqCjkgMCBvYmoKPDwgL1N1YnR5cGUgL0xpbmsgL0EgOTcgMCBSIC9SZWN0IFsx OCA3NTEuNTM2IDE1Mi43ODQgNzY4LjI0XSAvVHlwZSAvQW5ub3QKL0JvcmRlciBbIDAgMCAwIF0g Pj4KZW5kb2JqCjk3IDAgb2JqCjw8IC9VUkkgOTggMCBSIC9UeXBlIC9BY3Rpb24gL1MgL1VSSSA+ PgplbmRvYmoKOTggMCBvYmoKKGh0dHA6Ly93d3cuc3VydmV5bW9ua2V5LmNvbS8pCmVuZG9iago5 OSAwIG9iago8PCAvTGVuZ3RoIDEwMCAwIFIgL0xlbmd0aDEgMjk3NzYgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngBzLx5fFRF1j9cVXfr2+vtJb2m093pbNCEhNAQApHcQEAgQoIsJmAk oKwuBGVRVIgbqwqOCy44REdBQaVJBBIWjTqus8iMGzrjyMygqCMjzwyDjpLO+63bQXGeeX/v533/ ehvq1npuVZ06deqcU+dm6bXL5hIraSUC0S+/enYLMX6x6wmhiy5fvjSaybsHEKLMmNcy/+pMPriO EOmD+VfdMC+Tjy8lpF5cMHf2FZk8OYt46AIUZPI0iThvwdVL8V7+izbj/f6rFl/eV597HIV3Xz37 +r7+yR95o2tmXz0XMX5Li/Aoall8Hfrhv+v4e1It187ta08bCHH+fsHSC4aWDSNk2tWXVhNiRxdo NZb8g1SSTUQmjGikhEzDTCrZy0RCntdLjkufm7j21VmOyn+ZAiYUEPL4XyvDPH71kTnTvvvubI9G THloqxrteQXglJHpSWS0Rr777ruVWqYnXnPuN3bP1NZqm/AM2Y2AjvGMIrQhANHCMx2KrUzvROzy GHG7N1HW1dstPNM+fLBRXnxfWeshYReZRQajeFf7NF68q0Ov4c13dQwekYlLBhlxuylTrXjKItVB gJUgMOLoS9Uh3oSwDeFFBBkD2kU+QehFEISnhMfbx0bw4ifxIke1R3gSU9TxfBuhF0HA6J/EXJ4k X/eViBjVLzpUK+/+FwZUSPgFoBx4agitCLsR3kaQyGI8tyH0IghIPY66xwkTHhcea9ciWrVZ+DlZ jcCEh4mDUhLB2x/s0AzcPNThcJfp1ZpwP6lHYCQlTCTdCAyvvQdg9xCG5rXtxYMMFNZ2mO1lGtpv xKA3YiAb0WUbntTI60jx9hs73F4++NvaHU4D7sb20mQm0aH5y+qBhesJFeYK15A4iQirEOcgvhxx GPEc4QpiM8apdzi0slb0V4XmVUIW6YfqasFLyhDXCEESMpota7dn+lnWXtS/DDMeLfiNJg7BRpJo ahKU9rJI9KCgG8hf16Fa+PjWtWtZZYeFOwSFeNCqFa18EcdhwYw1Nhszmdqh2so2V1uFqZjmVKAl gjFSYJk/deGadryo2imMEbKJF3VXCmGShXiskGPEO4THsEkiwqMdBdmR7oPCvQbUz/hL0f3IDGmN 7LDZy7qrVWEkalPC3ViAu43ON3cUDCsj1QVCESlFYMDxaqRWI6UJG5DagFXbgJXagJXagEFtAPUR YT1q1qNNibCStAgryGaEbUhzsspqB0L5Zshqzysq6xICgh+I0Q4ClRSlwQ7Vzkfmb3e5jWb+Dqu9 rOqwcB2pQ2CY8tIOn79s8UGhvzGVAR3+EAdoaQe5HhZ8maXBm7x8SQ4L2UAER0xYyGnPiqSqI8hz Qo4Qyt5iRziS2DvsPb7c7G3kefyrvvg3ffFvM3FvNzuS2RTs9zw+Vp3NPsXLZrGPyTakGDvIXiGl eMFHrJOvPvuQdZEqxEeRvwJxF+LBiA+0x96IdLLODkQY+yPtNi+fLHulPVHSl4jk9yV8ob6Ey1tW nc9eZi+RbLziA8R5iF9i3SQX8YuI/Yi72VLyBuK9bAgZgfj5vviX7BAncbaf7SPDEHe02/kQUu0K j3a3yzx6rp1kcvUlkUPsObaLBNH02faCICqf6ijIizgO4n2UPcmWtocjrmoze4w20NNo1EaO8pi4 2OPt5fwlm9sPRSNdbDPbrPvL9Xy9WN8ulOaXFpduF6L50eJoeXR7tFpjd4OBbGPYv2wjnuUkykA9 CDrCZra+XSxPVfdgTnxejLTi2WakmvFsMVIET81I8dpTRqqK3UHqEBjesQphNUIrwi1ExHMlwo0I NyHcbJQsRWoZwgpwkxZAtACiBRAtBkQLIFoA0QKIFgOC99wCiBYDohkQzYBoBkSzAdEMiGZANAOi 2YDg420GRLMBUQ+IekDUA6LegKgHRD0g6gFRb0DUA6IeEPUGhA4IHRA6IHQDQgeEDggdELoBoQNC B4RuQJQCohQQpYAoNSBKAVEKiFJAlBoQpYAoBUSpAREFRBQQUUBEDYgoIKKAiAIiakBEAREFRNSA 0AChAUIDhGZAaIDQAKEBQjMgNEBogNAMiGOAOAaIY4A4ZkAcA8QxQBwDxDED4hggjgHiGFuxRzhS /SpAjgDkCECOGCBHAHIEIEcAcsQAOQKQIwA50jd1jghOMN2A7QZsN2C7DdhuwHYDthuw3QZsN1p2 A7bbgE0BIgWIFCBSBkQKEClApACRMiBSgEgBImVAtAGiDRBtgGgzINoA0QaINkC0GRBtgGgDRJsB sRkQmwGxGRCbDYjNgNgMiM2A2GxAbAbEZkBsNiD+Xy8Nu4U2mHDWslbaz4hXk6+MeBU5asQ3kz1G fBPZbsQ3kluNeCUpN+IVpMCIsdRGvJRETLQ9Uu6o9oIF1CHMQliMsA1hN8KLCIqRehupTxB62RA9 V3Qodco2ZbfyoiLtVo4pzCHXydvk3fKLsrRbPiazaHWI2Qw+CtZCNgGOktV4fo2AQwTPKiNVxZLo Nwk+OwT/kiypO09Gv+5P3+5PX+xPd/enm/rTapVdSEWD00VJOQMCaINuLRgZOYpQXlA4Epzp7n1f +SLtBUMjnfRQJuqnJ5D9CmEPwnaEWxHKEcoQihHyESII5QX9Adag5/a98hDiQoQYQhShnHi9EBNd TpPexWx0e8erNqLyfgqLAHewvbAUUWd7YR2i/e2FcyLVKt1HCrlURPdiU+1CvLs9chzVz2aiZ9oj B5F7qj2SRNTUXjgQ0cz2wt9Eqm10GomIHHRqXzwFC87zF7dHpqPZ5PZIP0SJ9sIC3ro/OspHbT9I 1McRI21A52V6irdHRqB1bnukgrc2kUK+8FQmxcbwJKR5XujAgL7uog0i1S2Rk5F7I19hvH8DYkEe H0Y7RURv53fS6bo5cqj452hcHWmvNvP2OB/29MUpHu+NbM9fH3kE76L5+yIPRQZG7i7uNKH4Lox7 vdFFe+TWaCfbpbsjrZHSyNLi45HrIhMisyMXR5ryUd4euTRyiA+TNNIGtmtfpB4vHI9Z5LdHLszH WDDEsZEbInqkMFIRPcTxS4bxrkHJxYc4BkhZpvcBwG//fPTeHplW3kmden/llLJZmamMUkYocSVX yVHCisfkMmkmu8lqMptMJtkkmpiJmDydvcf0BNcTPLKhLsgiz4hGWmM8jQeehFETIxNIyi3Ustop o2htqvtyUjsnmjozJd5JzZNnpKT4KJpy1ZLaqaNSwxK1nUrvxanyRG1KqZ/ZsIfSuxtRmmLrOimZ 2tBJe3nRHaGUazQqyR13hboIpYE77mpsJH7v8ip/lWuks2JszX95NBuFzTWJH3/+85Ph1AO1UxpS O8ONqTKe6A031qZumRK9tKGLOZhtTE0Xs/OosaFLbGGOMRfzcrGlphHNjhvNQM12NCOFPEIz0ygS 5c3AT0bxZlijTLsCgKNdjEdoZ7aRAqNdgdlmtBMpb7fnaHRMzZ4oHmiTT8hRo83RfHJeG1AMYGv2 FOCBVvEobeCtaEM8agysn/GiSARNivFAEwp5z3hRhBqdpUp+bJLf12TID02GGH0JmfEYr+EPvMZT dK6NpwhtfkTk/7fU3FEJ2jFo2apXxsyNj2mOj5mL0JzauHyBP9U6Jxrds2oZr4imhILmOZcv4PHs uall8bk1qVXxmuieQQbcf1S/wqsHxWv2kFfGTG3Y84o+t6Z9kD5oTHx2TWNHVWVD9U/6Wv9DXw2V /6WvSv6yBt5XlQH3H31V8+oq3lc176ua91WlVxl9jVnI6b6+YY+JjGocjXXlcQezmEHDzaFY4yiv 1jKSE3TXiJh/VeiASOhTxJJoTFnjo1I2BF5VXF1czauwz3iVHcWOvir/qhGx0AH6VF+VhmJnfBQ5 txCEw9emhkyuTcWmzGjgpJLSgYL/tmbX8Z9R7SdjFtbgP/JLjbD0uqXn3shjwlv+79/S//ZbtmzZ dUvxWJa4jpDaVP8ptamhkzESRUFXzTWNKBt4rkwQjLI9qjqms7cblQkMgi7l3fFUgiaAQd1MZKKw NrlNYVyLWNoRDJctPgy5YTUC1GG2oh2mBF61oiM3H9oSmpQMycRQV3m+PRgrQw8d5QDlcX4m1p3F SGzO31y8ubwtv624rVxG7b7tKIxs50dpe8l2gSxNXHcOGUgubQSyMSze32Pt2WGj4zaeSCQaE9dR A1/n2v8YG+XI/ohYzNH4XWe8nuPbwDCePAmk81qsR6b3ZTzHf5mEAQs8G0AoRatMzijijx9/yMFU dIBkG2EHyRYLoGOR3uPnQnph73Fex2P2JTg5LEg89P3ayTPkA1pEo6SDfkd85FsaoIPIeFDnN9An dpMecj/U+6nkAeoiedBGp5HxVESbBLmTPtK7vPcLcgH5GXm8dz+9tXcn6jeR18i3GMGfcGKWk0lo P43MJV8In5LG3oeJiawlFjKCXEy9ZDZ5H//+hXHcS+4jL9Cber9Frx5yK95XSapJde9LvWdJf3Kn uFk6qu4l95CDVO69vHchJKRcsoElet/v/YQUkEbyC/IMxpSg3eI4EiNXkjvIgzQgvIbU/eQJkqZW 1iSMll5ET+PJdHINWUE2kJ3kLeqi9dJR6VTvjb0nQIVuUoQxLSRf0CF0IntStPaO7P2IzCRd5A3M l//rFmeKO6SZ6areR3tfhva9n5rpIfqSVCbd3XNL72O9z8FeWUAGASOT0M8ccht5ibxJ/of8g63u XU3GkSno+VUaplFaAIy/zwJsFVslvEMGYrZNGO0yso2kSDs5QA6Sw8DNH8gx8in10BCdQOfQe+g/ mJVdwd4WHhGeF94Vqfg08B0n+cDRUvIk2Ud+TX5D3qYS3l9K6+kiuphuoY/SYyzFvmLfiCbxNvF7 sUcqSB9Lf987qfdf0LmD5CKykqwGbn9BOsjz5LfkPVgl/0nOUI0OowvoYzRFj9GvmMpyWR1rYQ9A e35WmCTcI7wkDhFHiVeKvxE/ktZIG5XZSvrs9vS96WfTv+vd3/s70I4d7y+AAWchuQVU8SR5kbyD t39IPiZ/4fSD94+gM+hl6OU6uo7eR5+lr9Lf0S8xS0gc+JfLRrAa9LqYXQs83cruZfeh97e5pQNG io/Z39i/BEnIFYYKS4THhJTQKRwRPhM1sUAcKA4S68QZYi9Wpky6UJoiPSXtkl6WTsmV8hVyi/y5 cqtyu+nXPf17/pQm6QXpVLoDtGsCJa0EJn5OYAQELg6St4DR32LEx8hprEKQxmghxl1Bx9JaOpFe Qi+lc+mtdC39GX2QPkIfp89hBpgDUzD2BKtmU9hsNpfdztayu2DLeJ4dYG+y92FQOYmR+4S4kBAG CeOFGcJM4RrMYSlMebcDs/cIO4W3hXeEE8Lnwkmsmk/MEZeJK8WHxB3i8+LvpIukq/HvcelFqVv6 nXRWOiszOShnyyXyIvkp+S+KrAxV6pX1yrvKP00tNJv2x8ijoP0ffiyAPZjDdjKPuJqeRHEYWocD M09gHaZgV/yTVAlprIud12NsWSwgujm4rIspCIJL6UEyhL5KVstMgGAoHiPt9I/smPgKu4C8R5tp QNwhXCO9xWJkF7jRZnaIHaSjyPOskk1nWwVCP8Wp+Cno/XpyH72SXkd20ZN0OL2ZltPV5F3mFabQ 20ll7+NMpCodT08RjIDcIl5BLvthCv81QStgnf8i/XPRJt4E/tRJHsCKPkM+oU+T76jU+xW4mwBu NBtc5k7Q+x2Ec70m7LPV2I8BcJCr5LfJ81SGDb1cHimuJKfIv8kX0gFQ1Chw0xPpheLPxb/2lvcW Y4dhl5GnsO8WkAuxYz4FlRxGnucuxU43g5fA+EjqyQwYz24G17unN9W7tfe23ht6F5NfAfY7OoB+ R9uwIzoBUQm71xvYJR/SjdiHF/7X6f0/FqavIN3kS+qn+bQM++GktFzaLO2UnpdekH4jDwK2byeP gKL/Amo2YwaXk9+RL8k31IS1CZABJInxDsPYG8hVrFE4TEbTIGnBni0CHx/VN5Pr8JZbgb2t2M+H sTdOgU9cSl6A/YxRH2Z0Ofo34T21wPMsch3ZjhW8jXag5Apw7f7kb5i3nQ6DeWAA0fGmB8C1ujGm P5LPgO1eY1wDwBdq6HS86xtyCbkCPQwl9XQPVmAfqQBnrRF+DXznUY2Morn0CcA1Y4faYfyukP5K GRmQntQ7jC0UDuOM6UV5G06vELmALsEoHJhHD8midWRI+mKM4R0qiCn6e2MUD7G5vWuFFemryK/I 01gTXVyu1BCiV0/Vq0ZeUDlieMWw8iHJwWWDSksGFg9I9O9XVFiQnxfPjUUjOeHsUDDg93mzPG6X U3PYbVaLWTUpsiQKjJIBY+Jjm6OpguaUWBAfN66Y5+OzUTD7vILmVBRFY3/aJhXlcLNR9ZOWOlrO +4+Weqal/kNLqkUrSWXxgOiYeDT1m5p4tJPOmAxtInVXTbwxmjpppCca6c1G2oZ0LAaA6Bj/gppo ijZHx6TGLl+wYUxzTfEAusdiHh0fPddcPIDsMVuQtCCV8sVb9lDfSGokmG/M8D2MmGyYYioYrxmT CsQBitcI+WNmX5Gqn9wwpiYUizUWD0jR0ZfH56QIl34TRhMy2ugmJY9OKUY30YWQblNkY3TPgO4N d3ZqZE5zwnpF/IrZlzakhNl4x5iUM4F+a1K+lcf9P2bxcsjJa8+vDQkbxvgXRnnjDRvWRlPdkxvO gw3F+BsaG/EOwLL8sc0bxqLrO7FStVylSrE7GhtS9A50CWUh35hVZn4ZTSa/eVE0pcZHxRdsWNSM pQluSJGLb4i1B4N6V+8xEhwT3TC1IR5LVYXijbNrsvd4yIaLb+gI6NHAT2uKB+zRnBnE7rE7+hJW 2/mJuUB6ps5IGc15qvbiHzBL+Rjj4yGPp6KXRzGShjjmNIw/5g4jGy4fhgXAr5ECKnUFVmRhSh3d vEEbzssxRZqS8rV4dMO/CCggfvKrn5bM7iuR87V/EV7J6eQHUkvR2efSqUQi1b8/JxFlNNYUYxxp 5IcUD1jeyYbGWzTYRoZCEST1wO3sxuElQH8sxhd4Y6dO5iCTap3ckMlHyZxQO9FLoC+xZl6DBczU ZE3jNa3nan4Ab46Dkp/ndguSlTIV/PDfoXndYxYMT1Hv/6F6bqa+dkq8FtpNdMyG5j6qrZ36k1ym niMUeENdXyrlHt0ghBjKeIqFBKMWRHnpjB+aINNgTYn5+C/zQWN3CCBKo4BGx6a05nGZZ6M5Fuvb Mv8bplMxnQfU2XuKQxnRj2B9s0gNT/SNMzPq1Iif5H8yOusGoXYqOA6rnTpjwwbzT+rGgpdt2DA2 Hh27oXnD7M7e1jnxqBbf0MV2sB0bWsaAC2UWtLP3wMZQauydjZjKAjocZMvIqD1xum7yHp2ug/ra BRNTdN3UhnZG2ejmUY178lDX0BUFyzVK2Q+lvE2U50gtBaG3M5NRFerSCWk12opGgZG/HOYloyzT CGWUXN7JMmWa0a6xsbEYAj8sWxWQZnaSTvE64lLCpFF6ncxA/kqE0eIzZBrqlyF9HeJ70WY6wuMI gxEmIhQgzES4pC9MQVyN9m+KfyWL8C6C8ADCbIT7pOnkfpRvkSvIHLzvTqQflXeSe1D3IMoaeb3R fjqZgLoBSN+r3EUUaXpvD947HmVrEU9DPLWvH7+R/iv5GR8fq+jlY1vP05jLKtTdg3AxwkaEmbhc 5fClGF8E+buQtqBfFbEVwQ6bQy7iRYQAMXzbEGgzMk53QqI4DzNmQAE5kUh4QmvH0wTfAzOkSd7W hrPWAU8GJ3FBl/JAP+LW5MzPh8gPKYPfOWfjpM5BPmJURaGx5UKLyUMuH/pCIeQNgptqAmnhp78E zuti6EoluKYcBOlqMCSWIWQopJNhkAuGQ6ushOY1klRBsqiGxDKa4PT+/+1vTN/IhmIGd9GlrFAg uAjfILwBw1ChOFZ8Q1KlP8rrlCzlt6YFptfU+83DzHPNf7Q8ZJ1o/dI2y/aC3Wrfbf+nI6bVOic4 f+sa6vrc4/dc7nkn67R3sW+577T/ZwFzUAtuDq0KpbPrsg+GJ4fX5szOeT8yKfLr6MToi7lzcv8R n5en5ecUqAVvFG4qYhgRhBVQLV9gAes76nlG07LSyap0N5HEtEDMipimJGCSpTQTDtECokJB9BN/ QjtT2VM5STtdObGnklQhrZ3FY1BpzBlz5uMBizI5GxW6z+oS+Z5ExW70BcmX0M9hm5BARTceYIOJ hZXpCbOkByJJhxSRmDTDNEwWGFFl8yYLtQR8QUEtkE0FilhAhQImH2D3wXh0n25lXOXdRAUaMFs6 qakj9tkuWIQnnW6qnHj8uHYy82+SNmZuzWdNGF5V5USt57OmxKBSOrZmbA0VMEqBPyj0jdJxf4Q2 sJJ9ThvST/X402toIH0Co3X1nhBnSu9wrwk6W19rEhXXOPM4e4O5wS77rT7qybJ5qcdl8zJ3jtXH 3AE1SD1hNcjcxBSiHsEUYu6I1SdpTptX0uw2r+ywWH2yI1sNSppoCkmaWQ3KDsUUkh1qMDg+ZPKE Qiab1zveZ/X4fFaH3W6xmM2KIo/HO5yRSHa2KEqdbKs+i3mysvx+Qsczt8uVkxMOC4yZvD5fMBgy 26xW1UQ8bremOUbarDt8f/PusOn+YNKm5xUkq2x0k22bjdkmxWRJYnRkSN0R/JtpR2lIDzWHhNCk 6OM38dVtOt5zHKtbqVUifW0icdrIIsdXG88qXlPpqigxmvBMT1/qjFHDa1FkRHiulQYmbtZ+uXag n0eO//hhWZrc8SGDEWLuwcJgHrLiCDEh7o4LcYqih9c9X3mKhuuO1X088fP6Dfsr/5k+VvfJxD/V /YU+OOJPw+nVf6SFH9M16ZU8fJz+8I+ZlLA+/SEtBMU19r4qH8ZqWvh6kgS4R7s+KZK9OJtmvxfO 8YTDOWFrtuzJiUaSA7JLw/Hjw/5Vejyc6Kce1/7lPx7JESi5QLuAXQAkkwJ6qoAWXJrcTQbQUwPo gEsd0UiUQd5W9TBY6CmZypd6dhMrPWWl1kvroBkxEqicONqfwI5pmtjTtOQMD019iUnnyLRy4snT J0uO4+F0VVAEV4XxWDsw0QS0DSp1J4cOLoPSIcdzC8o9Pu/gsvKhQ5KFBfFcRaZxOpj+H+obn73v oWd5+EMsMKA4EI0GigcEYrTyiGB7K/3isw9s+bHSH0NlsT8m1r/6wuHXEN7YNCgvb9CmTaX5eYO+ OyFbvl/+6gsvvPraCy+8bhRtMqo5D5nR+5G0HVjOBd8eRpl+vcVpLgk6AyXlkfLSR/O2258OPBl9 Om/7QKsqyvGA6IvnC/3DBbFhpffFTwqfBS3Z2cFw2BYI+OPxaElJ6bBhNltZSTwgDBiWHRTEgmiY CjhmBHlYSTwazg4GbOqQfrPddMiFMvgFCQ4veETzlniZt5PertvMAx5xwKlrs9amiVonzdEdZY84 zBFzqVkwByomgtAz69HTdFJDmKR9RqqqJp6sOun0AfV8BRD7KozcWs1UqSDweI/MRk9t6Dgep3Hc psELKBlEvB+xoOHBbb1NjYNKSRNtylcKCmU5Hi0sGJIcWl7An5kVVNxDy32yrHi9lK8hllDO8vgE GU8s69ByafvOm69rfGND+u8brnxqR+1F7736wvuLHvt1XjBdMCxacn9PwUVTJ48ZfZHeb3bziitG rRzX8eEFV9Zf9PCKR+7685TGx8bd0fXynY1tc9P/1OcPX3tz/wELBevwan3oRaMHJCekVw/aMG7m dclKfvJfmZ7MFmDFNDJWtxc5dgjMpMLDUCMu02Gay10N8STguWb1n9ZHomKpyMRO9kCH88krDT5x suc02C3wxrc638g0XsCGaJjdYMayPC6fl8196aG2y6ff3r1+/gVD4unJJ+g/voBpjR07nP5d+pK/ P5F+6pF5fCSjMRLdGMl43V/ICs3z2XzzFoiZT9kV1QTXR4xJ42MiOIWMMT1v+qf0iJWPxrUIm0s7 c7Ln+E8H4x4pDEkyYbDXleVRmDBmSs3w7HnrX9yyY1TtM+nJ7S98+8myv9OnackH6Zxvf/d1+nT6 ez6SaeQdcbr4LnjFOD1gElQmzSkVdIEJ5WxOFakj0HjnyOZO9riuSXROHdvE2pjAAtYfdvhpnIXH SUnT6Z6m4xm85OOwOfePvpdupa0Qum5Jr34HZjCF3py+Lf3v9G2872XpLvok5Ra7qr2qySKbFU64 IXkrHYbD4FpaoOQ5wMCiEIpEErDOX95HxMd7sAjgHz3UWUGcFRVgFjEwClkpHDq0PH4nDfRfNqN8 2ji2jgbeXHlXS3Rp9hw4oFJSTdeyhawNe7dMj5VSHYadcuxkTYgKpYIo1Eia0ZdAAuKTV/G+jjdN 1HColpxsQheYUzUrgkmUH5l42714PIPRCyRPz2LDiJkVnDda8YfR9vCxDiodDPh7cfga0IxMx4lr l7ohV0bJvXrt9eZ15h10p7JT3WHfr76hmqY7G72NwemR+c4F3gXB+RFTBauQh6pDbePZeHmMOta2 Q/0Ve1P+pfpL24fsD/K76rs2p+aP+pkfF0F6vsub9G832SKOEgdz6Mg5thMpfLQOlvVgrueoJRB7 52UDmxPBCs4smQiEnkws4YHTNWlqomU+r1NTwH2JUysf6suVFdmpeY39OtSpFRSwsveu37R5xXvv p7/Dc3C9N5ysG5yJpO4Hn0/PSjfvewAix3b6830PfFE99eo0fi/B4nQV0M5eqgYGHwfyC4ADlUzX 1SvZjXA1E7DjaL+OWRLF6X/ZfpMqUWJVcTvSAEqkrEm3SUSMiFExJYpiwHyA7qBtENE4b6ucyOU0 QwI63XQSREGaYjGnrAwZmlc+WChIn3j4d9dQVnpcjG8e05v35hq+hoMh8lsxgjCt0mft9e8LdoXe El/3H/EfCRwJmkaHRmePDk8PPCLe798pbs82ycEoKZLLg+PE0f7RgdFBU54/L5AXFLwF2EPr/FtD W7O3hndm7wybXCSshaPhQeHl4dvDm8Pvh01hvi5eT1YyzDSrI8xJjXHK1kFA/GYPa0Q62WMdjFod 3EkjHrGWWJmVr511u1tSj4J71mHIwYjjqLaCBXLOLeBpYwUrIfZhEXsSS45DRE00Lak0ztXBiSZ+ 5UfCvd3tzgo+hnaHEel2rUI0aRWSyYnYWZG5dWvMsHvdooYCIRZyU24bx4vwn3N52lQ7ueEwCcHw k40Q7j02bNiwRrqkCfTijA11lQ89x9+V/KF5fcxfFmVFtJ4t1Nq+eiExfG5jwwJT+vMANb324bcX ThycPnOhl0rp7++j6h/2VF0y7bK5i27M/vytL5+7vGNO9en6Ar5KE7FXQlilfuRDvWxt1ptZ7Mbs jdlsu/C0tMOzTzgg7fN85P84YPJ66F3eu3wsBlcFkfrc3ljEplnNnTRPt9bZqG7bBGHQRnFgMt0R cZe4mZuj1709JFGgfK8GugL9YZ3KUCxuL7SlrN1YA6tXO7o6simyLbI78mJEihxTjtbl0bxgwnvU t4IeJYH+59YC4kxmO4ECnRUlkMeNBeEPnl1ykks6nGkZKOVYBVKBPtLkzjf2lnE6KuXevmNSyR/J BmMngqN78SDx3LyJVLNdO/mSFddePLQ2cu31DePHzbOke0JXv3LD2zfPf2fVlvRnv389/R29I7bg mttbFt2U9amw8JIJDVc0D7hj28zbr1r30nWhQ3e8lD71KfYTkCvWAK9m6Lef6BXWqK1CtQasCesU 65XWv1jlkzYqi14xXyyyjbPNtO2w7be9ZlMpXGussk2RzBabQqxWm62TPqdDYvEIYKLMKtoEGxPN RNFt3bYjyBykRVCmGX1+HxFFABA4aj0vbTJTrAzTXRqc0F5UBCXoqGKrGWMB+wF6ER1n7OrjSyCS T8Te5hu7CkJ6T1NlRlg0cOiq4MK2mBGzz5FusfUC6JG/sX5slUiGaIHeBA6kIXSwE7K2kzopW9Xz FLvpq3370qfSu2nhGeEXZy/7Jv0hy6H/SltAcTNBcUOk7eALmt7PZI9ay11jXOMDD9l+bt/i+siu upxuV8wZd93hAjuiNjOw4HI6O1mb7rXbPHa7zWX2cLVNp0I93QyG9xPy2m9QV8iG43yGbouYS8zM zAnRvB0eS926xeNNRj2lHt0jeDrpLt0DhUgr0ViJVqXVaYLGm2q8L7fDYRcdGsjxiI/qPuoLRuyd NKa7bCvooSOE6rhz3Q32Al7RRS/sY5Pg9aePg0ibeIKzS83gFihI/ECrTUtAmhy1dqDWOGQNejVo 9SeEWugGXhWIeQQUirMibyb1W5dPbFh5w+wbmo9vZid6/j7gsjkHqbhwU/pXvYTeEJ61eNPmtWuv jLHv0//+d0n61Id77375I9DiJcB4f9CiD/aSw/qIRZZlprWmLYEd0g7T0/ad7i77Pudhd7fzbbct SxrqrNFWevey32tHPMpB8jbARar4XVooCqbFUZgDFIW2O2yRWEmMASHeZGx7lUp19Yjaqwpw/Kvr 2E0pViWm50bEEux63kbcniVhO6/IOVoHZSaY7z/qCuT9sLX7NnaGyZ5uAgL7TkxOkHxH870MUqNS AZdwOVYgiWHL4gAl4IXUEHYz4q/oSJ8yTx3deKO2cGvq+/S3b/8p/Rfa/+87/tDz2KrJkxa0TJ3c Ik7JmVrf1nNT+vS7f06foo10Pb2XXnHw7Bfr71+5cdMdq0Gll2D/+kGlFrKmC078x/RBDmfSbAla hovDzOOk6Zadlhcsv7F8aDHHoDEIColYSiysxFJlqbMIFj5jywEuDtFn9jNGRQXuc9iaHSUKhV2k WbezOoEKQRuMItY+LEBDXlKJ/QiZhqvFJw3S4fM35p6AjJQlM+aLuVzllwgvrThzC03/j3LyNfEx Kv16WXpC2v0yLWXX/xs0OaX3M9GH9fbDOlZKbXtLTeFIsqCz91v9KiRed77u/kD6QBGXacs9t2tC AelvHUpGWMeSi6zXiJebIBVlrShcW7jF9qD/CdvT/qeD23N2FG4f8HRpV3B/jm+Fe417jWdtobgF 67gFmMoe+CBSCZWn84WBfOpVA+sGsoEH4OieDYLRvP5kS3ZrNmuDkpwtu4o4FaloVlqkF7EieNTo NpetKrcul+Vy6FxeEpSlyFF1ReJonYM6gmWBo8KK/KPewKAfSOaH08AQr5qqepoSmnEOJE42JQy0 cdQZtNN3EpAlTYkEPV934nxfjOcaSpX7PBISzkvTcVdf/uk7vzuxqHnl6nTPB2/c8ejyrll19c2z Jk1uDq5ovOTapY3z5wq+gY81P/H++0/M29Z/0KEbf5VeeNPRFa/TyVMvmzW1blZzzwVLb715+fyb 7+bWq2qsjqdvNx7RG0Y4a51zLStN601PS0+bttu3u/eSLmGvvdP5vPtV8paz2+1MuqdbGm2znBe7 m91yQFrhfcj3sfaJR1rghnmMb85IqASbk+MOG1PSYlFsTI5kDSWx7aUqrVM/UU/1bc62zOY870QO oRn2p81/tM5FXcH8zD61nrc/zyHbOHP/2/402BcQ3MfBysGv2JAktibfoLAy0D7NlMu4TVQzTx1z yUrnom3Pfk/V33xCc9Lvf/3Mu+yymy+eNB/7czGdkjOlvu3sjdTy/ifUmd6RXpa+Jr11v5C97oEb 77z7jlZg8U0IL3+BlwC3Nw7UQ8IwKsvDRLO6GyYsuYBGpVKYAXebfgN7Htgvzjit8gzk8CpoC1zb oAhvcn0BDj82Hp/95zntAZZscY30pmHfuU3vL2t2d1LSNFdyuH94QJemZc0L7lJk1esmhr0RShQj M3KGZTs62b3t2sM4eJbquW6abc6m+OAGcoCmxjRvFMaEYAxmV41qgeiT52w4XKRpmngSBrCTXMHD Qdxz+rhhY4ThgIvZoNg41/b/Q/oToZMpssxtj+zrXnrxGX/+bYuv3BxKpy009Nk/aM7CZxoTPdwe WW69qe2NyKARFy9beXO047uep5q2b5owI+0ypsugBBN4hBwAFs20uosovUd1tbwiKRfhoRgbtWhI UtbxQO6oXh8rRB0e/Uh/nClF5hLrMFIuVVkXkUVsrjBPWmCab/5ccEyQIcqoVDCrqqiolEaJ4oF/ hKyKYlSSPZIkm8x6MDzSzLuwBMNJcz4TBFnkfuO6XVaYJMIRzGTlZrJONhsezXgHDv1W2Go7WZ6u RlRaqraqTD3A8oiIFmoUek3ActnlfYpsTwCnyOmmJf4ewy52ztw4kdvESiDFJwxj4tqbDWMiIkWr rFz7y19mJJ3n1aRqgwGGy+W1KQtcE3NwoddFhN50u0k0H+hNA1Nn98giZPSMlJ6R8WMxAf9ozC0I 0ovpF1p79t2Qfo2NoBX933qNTkx3SAfObmDRnmNQzuDDQKQ5wLybRHFDcVSvWtGfLrBf3/8z8Ywo qrEsVS4aEMv3uiJZdVmsNGt3FsvK8sRz811uU9STj3uVUGGL3Aonntqiwt3gwMAkvrBLgv7uhAY+ UB9YP7B5YMvA1oGbB7YNNEUHloIle3KjJOouhXDeyTZ2FA+ack6964GKA1NiggsuTeCo2DA8GAzV UHKyelvbwxVZ6KQ9yKPWPW6u1zSi0bkz+gdcObhrpzkK7YUL37GyHBhwuIXKsCPIUow6ucGRi+Ew OYKE+zIF8QfYhOd2rZ2xeNaazU2PLZ+Q/jRto0UvP9v/oktqJwz43U7qakuMmqLf8JZ0IHzpQ7Pm P5MoPLT6isNLbCYmvpZ+VlIvubBmmir1dKWvV61Nk0ZdiqsgSmb3npAugz0oSN7XJ61R13vWe7fh 6ux19V3hXcu/BDVfLbIW2fp5+nmXScvUNZJJcSs+n9vn68f6C/mSUiQ9JG1R3xRetUhVtA7y5sUa ocfgPoKLCKDc6YduidgMeoGnhO7zF4smu253Je21sxyUH196lj8JvbNIz3UVmwXH1/bp5GtivCpY iiMxq7BNoQ4lopRCUsfqdYRW9a0LVmOSBmkIi8JFo9NQPY8neMwTEAu4ZRDqoSSL8ShntLGoz+vL iEiwJ4DVilU0Mir9m6/Sf0yvoytpktqeuqIs/Yfgk8t/8as32pbvZKGZp77ABcgMeg29f9tlqbHX 3v5l+rv0l1+BOBm8K4k0GxSqgcet1gcXYbtf6JsrzrVK/X0VvnHeRu8Cr1ThGxpaG3pIesAiRZyc LN2ufIdmChTu5qJOhib5rHR3a4xGY6U4mpwuUKFWqjFI2hs7ov+VCn8gQT7LJbDrx6CqGeY38D2I wxkiGolDpoBT0X0svL/5ls7m4vJ5E2+b80TPO7To45vKx82qrLxqysi90oHsgpfTJ36797a2y2v7 R8SXzw6xu6a/unPnvnku46vq+8HzT2GmFrJZv8AkQVzLl10RiZZKu3GMSKog5sOwYlbzLQTeObUC G4fbS2oJRm2lNh1qmKhGweJKOUlgRtbzZ2QsIOS6SkMh+M9tJWE/hSsk7CdsKx79uK0ECRzJsG1l QREwwv1i1dkv2LGeqDBYOvBt+uA36SXfgMK3YPS3Y/QquVavwuhlKV+JmkpNL5o+MYklps34YMNE MlNQMf4qfIvE5IsFqI0sGLWUWpjlp+M3/7fxN3F9hvMEsE9YQHoq/9f4tggne0awK3q28rE9+W3P PXz3zcHu4/clUXC4scNyanOmK8tNy613mG633uG7PaTKPjnk8rlCRc4if1GwKMc0zjJTnKrOsCwS bxRX+pcG99n3aa/bXtM+0E5odiFbjvLdpkeCFThcCVaFerOLZdXFN5yrts5N3Xy3uflu6+8tdsBr kEYDs1Bc6JrOItGogCnnlkLSDBS2mek5Kz7fdbFV2zLcsG/X8StJ7fRJrq6VYO5892HzcdNDZc+S BDcB9W1AOgSmMIiReSBGmGkGRyF8G2pKlubiJvghQhVb1ZTetvez9M5nurvu+j2U5MED0h9FdrW+ /Onnh5oOjmahb3o6Z6x/ic5/51N6xazxn75VftXNZ/6R/j79/fjkAczzTqDyeaywQBZ3EdBMR1ky CWrp7ojnG7Fe5fEliaRL9VKrdEzCHWiz1CKdksRWCQyLCcTEhA8pISlyjAjdnHdxaj2CnEiuEQed m/i1fdewVYYFfgnu6xLctHonLZIOfDcW43gUlPak9BzuwS7Qg/UKf7cIHklMohSEXfz8TSAP6vrx cJmkpTn5AKOZV/O3xrIepUXsmPTc9+O/4ZQCcoFwe4BYmV+3WIQCU4EFNg8qYFPoavbwpDk6fERS 5RclfbH+RPZAlOIhqybzX9WvzDg3zWY3yxY1NWKOswFiVC2B+X+BOFddZF7BrhefUHea96oHzGfU 78zebeJmdZv5NfVN8wfsqPi++qH5BPtc/FT90mxboV5vvo3dKd6m3mnezJQGy1y2SJyvLjAvZzeI Sg2rFWvUWvMlpkvUBrPiN5fYk2y4mFRHmKvsCjfTyKpqzmJB0acqfaaTCBBlViWropTJdmsZBAAN VyT1JlvSwh/GLO0WW9Kk2wuTFv5A0VZd4wmLCbeGImWKGbYeXJtWgfh8fVbFJgrJ8V0INb4KaOcj 9GL0EhVNqlqWMRrhIxNzmcBgP2J4jWAVGbOaIZUppoidwqJh6+DehgdgY+dkNbMpQ06+KVOTUpmi K6tN1HR4NVbhsCVqsbJONkx3gY50NCQ6GpGyCBc98BrboGUQtU9DcU9olX/XKoMBrWdJz5LKoB9G kAQKtONLMHgu5VZVYrTcBPKj9NUnabmnQMgy9R7bY4lysQqHG34GHSZIYkkTyIZSUI6Tgv3fQw/C 71Ohh9In0x+n/5r+E4Qrv/D5d2PFW79fxQNo6kGcYHHOGelvdbsqyKaA4DOJLuwGYJd0uCxViI1p 81jvjxkJZYrJoygmwcSYIqjAF3AliHzGIp+xWCa/bVjQN+oB3VJvabYILZZWC2uzdFtYhpuaQKXG S3ms26dMSaplxvHQjQ3MDwgzx1XGrs4FUYhemCS0lIk8Z7BZLlNVEATc2eIHRGXoiIugx3QVVGGK Zmikez8kVZNuiKtcIBtUim+F0Kp1n2WIqdUyxJjYBcGBSdMUPCTBK5ThDkocK9yBg6HN1G46Lsi/ FN42fWTCVU2JKSmMMNWZfiZsM7UJu00p4UWTJaMGDMYFmI4Hcsd0W0lZkkX5Q/EMQckWXY0NTLKp eBitx+ZEkcPDxBTFzwSfMoAVKiPYYGUS05VL2XRF9bCQMpGNUR5Wdim/wl8N+JydUP7NLIWsSJmg XK+sU55hMgVaOBPK/HBzkiGFRmJQAuch1PkgjbIG6k5/0LMHBFAsvPPdWOHQWbjwMNzVn5BO4Oxx QJd7XJ+2RdpietD6oF00UcVucij+Qv/16gqXssJ5fdYacb1pvXWN/Q7Xes+6rHW+df41QaviAiUE s1xBT9CfFVTcxTY1UKwI3sLdZkrMmjmK+18u2URLw3q4OdwSbg23heVo+FSYhbXCNkL5nVWpseZ3 dmSveuWH48WQtbmRsE8jBaEvgaSchFDMz4+MKEfgFILjI2PUahxd9uz89R1wcL4jvSp9ON2VXkUH fbZnz18/3r//GHv32IMt7YnhUJIfTj+aXgyBbsG/0729vWe/xT0kw9csRPwWu4DjYYWeL0tdni6/ cKFE50vvS8zlzLfZ7SSkcRHHQUyY3n9Ibt5IuLRvflJYc5zP5bPPFxUmahkNwqBgQ1CAmNAnv2Hr QjjtUwHi8QBM7+c0gPvpH6j94lU752yZtOjNlx7fvXz0ZeOGtEkHvLGPd6/tXOjM6vlAfDndPHBO df0CG/5CiKE5HcJ8suAD9q1+a4VjvOMSZZFlkZXf8LXF99mPqmbZJJt9Jq95qH2sfSycYzTV6bF7 HB5tqH2o40LHMvsN2jtmy/Xq9YHl4XXqusCaMFR6jwpvmSn2Zfbb7ffZf2GX7FGb1WOzWR3WLJvP m+/WPLTZ0+ZhHg+Jxji6gLgsYgIbPaQXEpuGK5B3Q4Vtckrulo/gbmZtS5xG46VxFo9lnY+13EF9 WqohY3AXjj6ty2COP4pYBhfgXhvn2YoNoQPXGkBomYFPKFY+d0wYyOJxJxSrc1iFMrX4b++1vvxS 882LOtI/f//aqZfNq/zDe4sq68blPX9COlD31q1PfpA9bM0uWEerdjXGerYKk/IaRk2YCdM+OOcE WKn+gb0zgB7RL+hydob3Fb02QIRqlAXVKMufmCvNLVoqX29bWvSh9f24tdE8zT4ttzG+wDrPNT+2 sGj+gBXhNeEHYlZXnJ/YOZEkj/W5gWBycu7k+Eu5L8XFJblL4rfk3hL/c+6f43LC3N+Wl5sXr7Al 47XmWltN7uj4Itvc+A22lbnrbRtyt5t32J7Kdatm1SbnwuXDHLB5c5XcuNmG26jpfj0QTS7208X+ bbilPcDm4h6tW7dCSAzRULFHIOMoZ8Xjg9Ekvzioh+vxZtoGH7RufMbwd1EPVmi4vS3ur/q/7oWt X3f7kr5apbAgODBS2KaloKnU0q+dGQk/UPz7PvUM3wjvIfqwRkNnhiEHceJarqgtSZxuShzPxNcm juO0y7AuQ5POBT5C4ZHAx5G++K/t7opcoAcRSt9sd/HcEd3hqrBFXRVmIzh42ee63YoyW4XZz4Oh gZ/jjmD9faJG1nDzcNuQ3CHA43jb6Nyx8e3mp3PNxn1NRpX64TqsEKqTYfz8UWhVuPuIVzQoi2uV E2g0uG3tpnsuuCjZ9ffmtau/fhqfNPmU9FH3zTffMr5kwDCaenvZnb3kxfSX6ffpx9n3rLthcnJ8 yDVwxPQbnmt5Zd4/3rItuXxIbkUyv2Te1Yc3rvrjlRTyA75tAE/qwh5WoLPES9RSsVSqV1tg0dms wgdJYvm47lKISYUBSFzNz1tarJtlBTYgfHYGNQtZp2Cvx7dlrWwzE1nA1PNMhr/iGnUPw6pwWzr4 Dx7wizrex5O4RkWbcHAM4RoV/SQ9UbwrPUl8+dtvv+d/COhenBh5GFWAbNCHKSZFVTQwEfVC04Wq cok6XXtA2+J8MOsR7w5tv/eDrE/lM7IFfnJQepV8t2q1RG1vc6GKbdRz9VA9d4RrCbWGWDRUGmoL dYfEEIXcHQ2UBroDQoALAsHzBAHDApORAiADnDTc4/hgl+AeCEvC1fmhQ3DmaXYGgypft3tpkcW9 6aZVrUFaVHrL0ed+/+EqTxiH4GeHh824ev4DzwmJs+n0tx890Dj7kWmrznCsK7DBbcT8rLRXdyWE hBy1DLaI8DWz6MHhSXzn2tqBWDgvbg8MgRRzQle5jS6AB+xMmRzhOSghx/RG+CeIUTwUiL2yNUiy 1H4kX1W+MJ+wfqP+2/yNVXpdetP8uvUj8i6k7PetX5JPVXWX+Atpl/lJ60GxQzpo3mt9Q1QHirlS iTlqfUS8V3rEfL/VlKHo503UbuMf4XbYY3xwuD1AAkJyjA95a0dGft6qZ3Fp+gqes8hQ/BSIzNB3 jZU/T2I2mGro+ZctohTt7C3tkCEwd/aW6ZcKxBolMB9H8TcNQKRmODaWWcweOE+qsgKFWvWYTKpo sVr7RGt0IlihRItWAfe18C2STYoiwXCJC5+MkI2jAfRbAhm6k5bq5qh82HJYL+E6DbLWKDdoMhqw nbNZBgPw6Qv6e3qCgZ4m/zmzZUZi5k/+zxg95EK45nAJET5la6WJ50vS3DfyPLnakAgNQXpJnxTF oyVN3EgJKdqNmFI6N/04LfmYWsEX6Z9p//TW9GswGX0MWnIKX5+Fkgipetz3nfhzVT2QqBtAQSby Kr8Xe0EfaRnSbaaiIEqCIuK7JSmTjjLq4RdfvCQqK9yDCLdgkMCxKvCAUuENbjbR6bAMzdctMlAN BQX+UOaDzId3y8y3FzJ4lEDj8O2nhvDMbSvzOlSOLG7RD2jHoVlkIuzujGahnTnOEZTxA4DHXZ+e YcJVK/QNf4InIAtUrjVxN0iYJ3F3zREAOZJ5e07QmbgLvJhO6/kU34FN7jnEas4+2/MQ2M343s/x dehI3J+W0SX6AiVoypbC3uCE0Ljs8fl/0D5xqkMDYwOXFMwLzC9YU/CzwL3B7XB3eT34Rsgqy7Ys rxzwFsr9shoDK9gatl3eK78mW19MfqixcF7ZIOcAW56eGJjM03OL8AiEk4vzzuaxvLGGW0up3ZG8 IEy5z0sq/O+wGA4PoIOJjlIuXTIyLaZnO6tiekjDA+65Mdw/7BUVK7wW+Y5BnRGj2ojRYgC/odA9 lpxBBaZ+apGtMWLdZmXQ43qhyul2+MQE65I02Qx+cXcpiGNwv9gsH/3ER+t8s3yLfYIvMHhhdZ8s ey3OvCUnm7iRCzZJnjvO3QmgBCZgLYI6Y5yEhskokdnM7SVhuqTxZCbTRfJ6u/eHwsmpeVfksaZE YxMgsICCHbYvzqqXwIK8hML3DJe83izcy/li/MyCK2Ru360Ivq3jV8K4/uFHF7ik4ShD5/Ymfv/2 oc5aIZSf/tKiKcK4J5qeODz9kZ+9elH94tqp9LKhX+aVN9RcNGawZmF/GfjwfY3r96c777zjouzy gGns2PZ1M+6qzc6PZk8eMyL9e1eZv7ByxPSygvK8uUD5WlDDfdgDDnyT8GgXHLy/1QdZKspDF4aY a7o83TzdO93fmP2NIg8RR9hGuIeExoi1tlr3mNB9ykOq2WrHpidBLEK7pHj4WrgtFgcx+2KmYEsO zdH6MaEA5uJ+upW2kFb0FwhXZfCN++GTPZWfTYKczXWHSn6fxQ0quHijTaMbdMs8eZ55nneef2G2 1AQtybDeAHX4tpBfwhVmuQ1n3z6dAt52t7a/nE73dM3co7uS429ouu32+XPXSAd6Tt2XPgFHwlPp j2Y2bmX9n6xr2bZr32Mw/sCnEXOvwk4IkD/rkxscjS4YgR0LXQu9N/tvCGxhW6yvaa/5P9De938h f2H6wv1F1reye5h7WNYE1wTvWH+jdaFVGe4q95b7hRXSCsdaaY1jfeAp1w5vl2ufV7VzivWHkjze 6/Ik7YNtvCSQkzRi3MDbDuCbYzNw5nJaiI6mREc7Mngz6PQAmLaIqqhPobyUxkiJjSdssTocy8GQ EvMEgg0ZVBq+eTCsJ06fTHDjHmx7Gcs64ozKApz2mfGM2+ByiRMdV81AiuKg9N/sl9ctvHn1lfXz sqgncfo3X6T/Rr0nX/6UfVU2Zeo9Ow9vnbm45IWXaQG+D1Zo/g6uh00F7rg9ndPNZr3Y1Sg3mhtd GWp5EKTxraq25LTmsOFC0jo8KxmYINRYJ2TVBB5SVU4n7ZKFU41utyh2B5bC7OtntxXA0aKf7nCQ 4CZOOzFTINxQaWxOPsMlZzIUY5yBmdtP3Bks4bRiWygvNC90ZahFbmqMxYb0TRBapw+a9fmkIs5O f1+9Z8Z+WCRfbr+VBnpcJTUrZ6+7ff4Va7fObMTn7TihaeA+pp1t2XnRNU8+sf+xbZhvNeZbCFrx kGz6iy6iYZ+MtVQ8pD5se0B7StphPqgetHUGTSYPHcculMea63Kesu2T9wVfN79hfd981Pqt8o3N lu3IztLBIbJ0uzPpyHox6+0sgV9DdThyqozY7kPM7tKhurnq7c12Zve7uLS/LxBK0sEu43ImHM1c 0uT2y8SJ4kzszzZi3QF22gaU4qqDkVkuF9DcIVpcfo7uPItCYrQkK0NEJTmzchbnbMsRcxwxk25z JIHwPm6Y+MltzUkI+7rHrxd5qvx6jgMPsGA/59VgcYnGqh5DGXBhImjh4hNCIyNGOx63n2uKS0wO Yvx9EXzN3A39gE+q3cejVIdqHmlkq2NVMJLh1cc5B+WuibrHrgNLdt6pnXePaylflfEnRBqNK1DY ViBQDDakTHALXCRlXMw5jRMhZsicbm7KVmQf+476h36xO/23OxZSzzsnqUvu0YVbZ4+aUShcP/3S ykpKLy55+LG993wMWkikX08fvnnjOHrVytWjR1/H+YYfG+Az6JNe0qnjXor2F6Na1Nkotvolk/ii n2V5nczj8jrtbnwLZodjg8Y8qslhobMsvbig4AthlqnT4aW9XngZIpuD7wDxkT8lsttjVgdXwWxV D6tdkVbinOVkzk4q6ja7u4B5ZpE2bzf35QdNqNakN+C7vostzLhsJcBS+RdHZ5ugKASOEz+YKr/d QIBHyZKKMv6JSd855Ib1ix9EPoUfOFlZ3N8Njmr+rRUPLbv+uoLRIy8Y8vvfp09sFQvq19w+Je+X WsXk2o/P7hfGG3s/PVlsNiSIEjpJn7MivDbMXFZby6A1ttZBYpTCRiCU0sFssKDT0Wy0MNPR6GnM n95veqKx5ErHt85v3a4RtsHeEUWDB0A59tYW1Qw4Ze3xme/GmW2x2iz9rbZCu9eXVWyzQn3z5/Ed sNfYAcYGsDsNIumwWDNxUf/MBsD9gVE/KJnZCGpWyDj4Z8FFeGl7xFHII7u5mCPckqX4A3L/fpaC oJ8zHTUQCAY3DaKDwII6dTMZnBdzBUp/4D7cZ4TzH3xE1WOoX/yw6jndZ887d/6DnjuwsQ0KxuIY 5Eu53MY9d7hvbAWX1/qOuCUG33Is9CzMn99vXmJhCfgWafJJ3swnLHCQHQIeDc2IE7AP1zIe6EpR CArnO/fcQKtN4aLp15Tnu22rut+/eQ6lL77aSpWRLQc3pf/xl7O3Nc+/e92CubeNLRyWlRPzDopf 9sgzeze9Ry00+Oz9Zy88dGBRZdfddnbb048+9vMn2x4FAf4Mumwj+LoX3wIlHDSCP/WBhdRG0VHO P9F/U1WRvFIea3AucEqUMrfH6XILHkbhMLJUDwsK7iw8WWZ89GgxF5hUPZqX3K3SXpWqQDN0HW9u XnKzv83PWvyn/OxrP76b8xR4OevTHWjblkVPZdGsgK8qw/ZhIuVWJUhkSJ3py2V0IFjeTwKnPkO8 MhmaME4DJ0gaN/QgZVylgrBlnqS71h2evbUunD4RnXzB2GsGp2Ex6vl027iWdZt67mGDdswYUrN+ Tc9XmDQY5r3YiM8gyX1xVnQRFSOrcpqrdLVeZa1qSu2Ga+DXqhRRm9XVahsKJEFW8GGggFNMN26h BNIEmUiW4M1sZgrOTD47NZaXFAOmvnkZs8qcY8b2NK4fjRtSnGfXcvc4w6kHnwFwpx5xHxXTZ7+f IBZ8Dw/I3sfTk+l2Y4RZZKM+0asUKFHfUGWfSWr14U85SHCxhDezpv7niMQseRYcdu5WHdRTwPCV hhTcxOVg6rMN1rDzArC9HWBXkhhbtAfoN2z6gYnH/Rz7hj2fy8JNxr0pOAqo2Tn4J+Pmo85yQjni 0ln5OR3/LhoYsmVZ/9nDBnnijkS5KzOZzd9//6sdlzkcp0QpP3mrgD+ARMl6UN4szMtC/slt/h93 2JzGjYZ+c6A4qeCKyS0XqvPk3eYXzW+ovzJ/ZDZPEZoFZlP86lj5EtNyWdqnfiKeFM+K/5KlScok 0zz5ZvFO8RFxq/Sw/LDysMkcEV1yQkxI/eX+Sn9Tia1WrJXMkLVhiDOZJTPuVEQLbpz5B6AWi0mB RdxswYc9V+tBqcRUEYElea6NWQpoK+HeUPB2rLqxT3XgVBqAz6Mfzg1cs8Xa4slxxbU2rqmd+0KK T+2NdjXW55DDr4TItdAUYALt094U53r4Oo2nM9L3w0D+u/S/boPqeoYuT9/Ucxn9eH36GXT9I5VO Me5Q9X6cRnFjylqlFP4mzhHp68zF6WqpDQUSpoQPVyGLU86cDGrExyv/ixqNw+FaYyygvb570lW4 y3wQ3L6Qjugi/QDdhL5wulqzZK81KSRNSX8yXsPGmMb4a+JW3Lv0m6I292vtt63fE/IOZbt1r7zX mup3pN+xfnbSr6RfPSpe7PdJP7mfHsxOViHfalRKSkxUgmF+HLabFa756Tmigo88C0PZ2QWFuKWQ HVqBy6nPGNLspIuxQTrZWN0RDBWEs1GGjxab4X+CsufzYVDikmQ7IYWYbYdDreKxPhTjLkTTQr0a oRIhrzBZqA+/IFlS+HbhJ4WCozBS2IqPkAujhaWFvYViYaDorxlG1HdZA4kkcwZUwh8rgaP2DNww EZ1jSXzpuWQKpm/wfODzWtgnwJgS+PIIvMnrM7Q/OOpjuY2PFDMs6kdutYoKG7vnPVA69vFLlz1e BJ4VLpw8YsHA9ImcqqHVC4rTJ8SCe56eOm3a1FmX1jzY08hm/Xxg5biND6QZG/vIjAFjb3+o5yzo A/fPYiPWzEu26X7F7XPPwAfUIv6cJlZLqzHVOL7QJNlg2U4F5iirxQIRnNECLzFYNmwjeMn/Hcs2 WwqsuCbo147bBI5Xg3NnPuz8Kefmp+X/Zt6ZjQHfRUN6x6c3P04e9+gZBi42pk/kTa4YvzQBBiht fKfp4boIy3lm7rD629vTEbFg6/OjF9x+I+fXF0MufxgztUGL26KP+5yeMH3j/iZLfJ19juuggBRQ WaM23T3d2+jfwh6UHzRtsXaq77E/SH9U37PiSk3+3KbtMP2K/Vp+xfSaVVpmWi/fbhJAW6BCi4+j yCMqngol2BxqgV+qPQZT4XlqV0Z5NVwxDcWVn+rqQm0edJGFfpE24UiHv0/ShWmBL/PvMgryDRUs o+lfvKFn6//QZPrNr36W/mYDjT5wzTX333/NNQ+w3DupvCH9+tf/k37l9t6nfv7UU21bn3qKz3dj +ipxC+arQe96WB84zD3OzVxJocJW4U6GaoTxtvHumtC/QyrX3c/pY2eUf4fwN1bl8/V0r8WCv9Fz Tk939rPbHQWaZihglv/U1CeeNL5bxtcA/6GrG27sXI7huvp5+hf3lMvilM5VTH4ccBXM+8MF4EYq D35uURdl6bNdDZvqsMTeu+fNuXXN5fPXYWnrr0j/Kd2TPpP+cOy0ni+Ero5dj3bseJzrYDMx9zmY uxN/PeFRvdxVyZK2pKcyewKrsdV4JmSbWiI0bMryJRulRvMltunuRh8+jQtvN2/P/lY9Y/vGY3US e4gvrWiBmsWNFYpDk/1QNHNc/aBxFzidhrFC3YSDMhjJiH/8q7dz8z/9E1MFbUrgqpMagpy00DzP vdC3MDAvDEGOOvkxWPh/9XX9QXFUd3zf7rvd2x/3a7m7vbtg4A44jl9C5Ag5RFkTAwkJgURiQh0E 00QbY1SwaVLHNrG1YrQ16hiDpk5idcZWOw0CmqB2hraZRuo4TVtTTRonTCeOrWlG6kTEqRz9vLdA bP/whntv9w522Pfj+973+/l8P5t0PGy2e/sqaVhaWftC16s7HibS6O0H64mUnfjR5lv3PnDLLU9k 7xDDTTc8dIj4CdaYb9z0LADg4ecP/WzgyMFfsTWyTxCkWt77P7dTB1xE9ZIbXLe6drikSnOj91ve u03Qhn1GniHuM2YMscFoRVrSMXGnXaIomOGSKGspJLKqVYAnqBrbbR4yxS5zt3nEPGlS048sboRz S2xdFPcAUkI8N9AwQnId9wLexfyEnuzEzoA7GLB3MI4ZKEKxwdAD8UsLDNMazpq8agmGPya4MxYc V0MOkMNsTi/bdn13x4ama65eV0mTB7ZdX/PZlde9lP037rEKM9qPeywVf2uPygG5wF1sBayCfrM/ eKB4f6mqBBuDovmGZ8R7Iv5hwZRnMiGXeNZ7tnj26wfMFxMjhnJdgV14ffK2xOZkn9kXfDDxw0K1 NrlcbtSbPa2+xvhSYG2FxclaoybOkKWaQkXWXAE1HvEUG4lEokApTNjl9xi7gt8NfadkR+lDoQdK nwntLx1ODBd49pB91o8jT5f+onSgXLbiYTtekA7budAeDpNzcOaq3fG2on1FYpEduSJdFGNhStvC utNWTqrKSSUS4xfGqzC4qkmc+ypYm3iNX3FWZsZ9iJbtOsY2Fl9iveExydkNMGe0MtrARcFxOewa mRCZhEkysTjeGG8nHdZmstWaBJfEEmksnhBTOR5DTMW6gAg2pvS2GIk15ijwBvHDHJO5d2fPghEh MfP2EHwpsO15zVC8oYWF7Hx8KK8QqQyogXmyc3sBDrZ5yOJEY6Lf82TieOLdhBxPGB5KwXF2vDWh mvltQ1ZFA2ru2vPzRFGa1fYVWP0FnvrURmg3yNATBDiHn+OZlP9mThi/SYjdAr5QF51A8g1uIWzD EQxXWzaua9mIF1h2TW3aYjFnyy4qQYHr+qw8Ht6l1vqYDZfDFyNtsZmYOHvzHNJE25aVMQYqmNUs 3OucsgaZDVFwGg8W7x68Op3syMKZMVvVzQZfCkX82My/XvNkjKCRYYeDBkM1P35Fz/CgBORQO+Zz CFi2IyK9GHROrrvDqZuFJ1nWHtszV5GYeec3t9cWBUMrs7+86ftnPjzzbir7eaBr411V+blJ8puO jZc+OT1NKsvWrU/lVuaHgoFV19749MNvPvrIomuX5oULFoZyb21e9eATfx7ALMqb+Yf4uOtZrIrv 2CX5ApxyrcRX5232dviUaEiISOGQYJk5wD9NMUgikqpoigFXmNg+wTpsDVhSN6pRRMgRfBhEWBD2 ckgIMSUURO0MHWS0SkGoJF2wEiw8kYpISctcH2oIHgoeCUrdwT3Bx4IngxNBlxD0B1maGkXActfh uVj7qoFa2ImrORM9ODPKIE4WuwDC6b/EYxcIBjPOIsjB3NWYjV10EgQqgsy5gFIAGo1BhwHIZNQU BcR7R/Xi3OLmyKb7Vt+b0dX77ycxmhzPtv+gLHfBmdLqtcsX7Sd/HP/LC9m9aJ+fwMrcgJyLsPBT 29oQuC3wlEtS5ahcL9YHoO0d+EhUuE8boHpY0EJBhGUQm0mGQoBrSwAs8H2SE8D5mn2S6mZDnW+Q 3GQC2Nn/bpC+ujtyFpl5x8HZH3U6gUzk+WC/yG/bwU2lNXW/3rrtpdUkmreuYUVvKYkeWr/p5pee Eg9nI+Nbrm7dcZ6MwlnEfUKXCCqgSTB8F9ghVypWmVZYIbPCzQpgkO8PoeZuaj4Q02cokUHTc2uG Dl9cNKWYGtMSQoV+QkdK5syEHUYEUhNcelCI6hBe1dNCnd4nqI5JGtaIx+DX0lUrjbwHlchIHAWm hW7kuUwZJPfogkYBRapA1WQcqxkWE7cjuam07snjPGTqAdro1xq0Vk5MqrJ1KmZ0hOtbAc+9LlZh i7rH9hl41kA+SBAQvTGOY2xFGRGtLNJykatXRB0VEXbOd+hsew4REcRhWC5ETxkWLCgws1ccCKK1 GGgLMERyNNtOit+qs2Sv/w8knkXrTf/91eXhigpxodOmKjyiJWhTg3xgL0LLQr9Z1BSXukAIiwtp APTRoLpQCxgGh6UL9IyUkVdIK+R+qV/muIC9s7wJTahDu4aqukaNBUKMhl1BNaqFDKNASNFiV4Wa 0oqNRUhIuVZtFJrEJtcKZaW6U9hFd7pA9dF2Gn3CQ7TPBcKP1mecFk7TU65TQKRPAZH+mJ53nQf3 87zxhfAFnXRNKZOArieNitk+mseg4YdyDDqEAx1u4WW0WWaiVsyBnUObmU+TmYeaW2ah5tX2VQxq /jr4WOYcTQHE0gbEs9GrbjwzgckZyOJ2QcfbRmahdzgf4PHxERJzNhsMPp5Fjx3wmEkWcfeKl+yI /0MsrjaPHqMjWcfCfgvMXg/rticDUH1q0JPBXU7BWOu2wT6ZgLHGJ6zC2fggegjVnOlmA4Kne7BR kcN+SFySSEd2gAROHCW+V94moezL2U+PDmNkrBCPsfd/zogvT6/HfDMw37r5fOu3H0kpb1GxXxkh Z8kpZcKDdIwYjchQBhCWuFcAnr2P7FC0JClTFpM6pZE0K/36lDylqEU0qZRqaVqnLaNrtN9R92qt nXZom+l2bRf5nvYkfUp5XTtFz2pfah6JKghghJGSXqpV0watkaohKB7UaWu0bdqL9Cgd0yapCibj xJAZYbP8/SHskFGP2yEjkCYUelYM+EcFJTPQavHNayUV6RlOVx63feHCtJQUwXEUVZes67NfTyBl gF3Dwtd6UnAhI8rFkG9RBl9XFxBy3T4oV6sseqK7t7RCX2kcuQUS+1isRgh8u22yeDf8GMZEosKW y/O3B/P10sUoiIWT/Ejggko8osKItmU9c5wA5wjjgEdYrYwzul/V8jGQ2Q06YRY2JtiS3NnT04ux 0dNbTXi/ogTngezOPk42vPl70pztJ3uzL75/RiwQpexZUphVp/9EVmaPMivqRcR7HXo1h6SHzZSL 5LBbjxhATMKATRRWyKxwhfGZyGxZHiwpgiTUo3tlvyjkyDQHrGkJToac040N4DFyBGbQ56n0poT8 UFWoOySx0Cf+dCiRTPOIqJm7MB1inKGMZEeiacZcPkaKbVXkZ+BlsDOTZAQ7d3F6ls8VZFaQG8GW 6ShMIbOGTtIY2q23xX8J0euLnZXOXIIldDQG+CxSgFOzlnIsYueqAT8W6Dos0IN4EMbrM+itmYlX JGhisywxDvi4GIkLUbocf04UhRlpAIVmYggnrB7EuXOtDmcSKV4JPlEx8wNrvcBVpkhBdu+yomUb dretXRNdWrPp5igmlFf89EtxpHPTNYnAWc89Haz1E/B6/orW95OWYXOMIh97ZsZe5EcOM0GhELcm fk6mNLFWb9KajI14kMhWslXcbbrP0ZPGJ3TcoFolfU55Q/w26BgaabdVFQQXUmk8x5d4n98vaPvo IWww85NXYuSQsmFVq/b7WGdgg85qu4jt0H0gjPqqfLZvt0/2xdD2o/CbRFNxVwt7jMeYq4VhoeIa imGxMzy5BR0+exleX97nG9jnB3bxACLb5zPnqrOsF9IF8LLBnGKfXKq/WNbL7N70ZxDrYM7XZ+dJ jzPK8aAQ0Oq8aiQNZq5WhVpT3AxnYICZYwbhjiHjsod3lYh1W9Mzut/A28O3qB1CdQ1ZXCsrLvDH CNLQ46EEeXRT5aK27F7pzuzt+3bkkqG/kbG7QfIR/3kiW35Q+ZxFIG4XGqkuvYe8CV143i5HpgH5 SEFGxml6WpHG6JgypkkbyAZljEg1ShNpUqQiUqTUEEnF8N1jL9dd0gVRdF3oEs7hapfIEpZYfw4B dN4DDIakMY+ypE07CbmDS7J6we3WL/jkfOT5sC/lqDGbcVoGyJu3CpOpYpQNEAo62ScwGIyrO0u5 LwLrA3Odl+RTFkr/gNRnj08fnD9sJMfJO9nqbP1cjf+Lv2aKhfeco/8rG3EuwWrJGFAq2sEQ5nQf 51QfLaCEUWFO6zGB7PU5ZUdkm4IxeFnBcU6/sU6oh1rjcqjFN0GBeiUeM7MKyvQtUHtuhWLzWmEd tPPbocN0I/L5NwodUNW+CQrNnVDxZy8imMyc4sVU/IXm9rXL1nSUXde79ZY7KpbedcfmlnZ89V9M r9L3CmVuZHN0cmVhbQplbmRvYmoKMTAwIDAgb2JqCjIxODc1CmVuZG9iagoxMDEgMCBvYmoKPDwg L1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Bc2NlbnQgOTA1IC9DYXBIZWlnaHQgNzI4IC9EZXNjZW50 IC0yMTIgL0ZsYWdzIDMyCi9Gb250QkJveCBbLTYyOCAtMzc2IDIwMDAgMTAxOF0gL0ZvbnROYW1l IC9KVFFDTlkrQXJpYWwtQm9sZE1UIC9JdGFsaWNBbmdsZQowIC9TdGVtViAwIC9BdmdXaWR0aCA0 NzkgL0xlYWRpbmcgMzMgL01heFdpZHRoIDIwMDAgL1hIZWlnaHQgNTMwIC9Gb250RmlsZTIKOTkg MCBSID4+CmVuZG9iagoxMDIgMCBvYmoKWyAyNzggMzMzIDAgNTU2IDAgODg5IDcyMiAwIDMzMyAz MzMgMCA1ODQgMjc4IDMzMyAyNzggMCA1NTYgNTU2IDU1NiA1NTYgNTU2CjU1NiA1NTYgNTU2IDU1 NiA1NTYgMzMzIDAgMCAwIDAgNjExIDAgNzIyIDcyMiA3MjIgNzIyIDY2NyA2MTEgNzc4IDAgMjc4 IDAKMCA2MTEgODMzIDcyMiA3NzggNjY3IDAgNzIyIDY2NyA2MTEgNzIyIDAgOTQ0IDAgNjY3IDAg MCAwIDAgMCAwIDAgNTU2IDYxMQo1NTYgNjExIDU1NiAzMzMgNjExIDYxMSAyNzggMjc4IDU1NiAy NzggODg5IDYxMSA2MTEgNjExIDYxMSAzODkgNTU2IDMzMyA2MTEKNTU2IDc3OCA1NTYgNTU2IDUw MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAow IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IF0KZW5kb2JqCjEw IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0pUUUNO WStBcmlhbC1Cb2xkTVQgL0ZvbnREZXNjcmlwdG9yCjEwMSAwIFIgL1dpZHRocyAxMDIgMCBSIC9G aXJzdENoYXIgMzIgL0xhc3RDaGFyIDIwMCAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcKPj4K ZW5kb2JqCjEwMyAwIG9iago8PCAvTGVuZ3RoIDEwNCAwIFIgL0xlbmd0aDEgMzI3NDggL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBjH0JYFTF/f/MvPf2Pt5u9t7NHtlkQ7KBhCQQApE8 juDBfQQTJBIuuUSOAN4SVA4RBW3FW/CoN2VJAgakP1Kl2qIUWq2tWiu1eFaUtpQqkM3/M7MbwP76 //1+WWbe983Mvjcz32O+3+98Z1mxfOVcYiGtRCLa7MUzlxLxFziOy29nr1oRzdxbfYToplyzdN7i zH3Otbi/bt61N16TuQ9phMw6Pn/uzDmZe3IO14HzUZC5p5W45s9fvOKGzL3/j4RQw7VLZmfrg50o X7d45g3Z9xPUk+h1MxfPzbRf/Ta/X7qkZUX2Ph/X55cun5ttTxsIMf/X/BWXDCwfREj94unDCLHh FWg1nPyd1JDHiZ4wopJSMpUQ+WU5lyi45/WKffqP9j03aIa95p+GoEE8/qm/FBZz4BePzrryzM7u eSoxWHBrFO15Bb6nH5oeR0ao5MzOMzepmTfxmt6/4XvJFKlPe8IXObpfKiLHkJhU1JbMjeyVCqXc tiERrVOKtzvd5fZhfaUonlgq8ijyJUg7kQ4gyWSGFEatinw1UivSTqQDSEeRdIQg57VRpCVI25CO IemkXCnUFo2owwolP77rx3jtkpd8i9SDJJEI8lKk8UgzkDYjbUPSiXa8ZAnSaqQDSCeRdESTvG33 V6Dv3ra7xaV94bXl4nZm5nZ6k7htv7Ixcx07MXMdeXmm2eBMs/6VmeJ+wzPXwpLM1VlQ3oqHt5us 5V3DPJIHg/Sg40uRU3aQ2CklEbJdcpMUEpPQVVGiSc72/ET5tgOSTKjEJErmkEhPl0TbrI7yYSbW w74lThJh37ATmRp2ot3mKN827Ar2CdmJdABJYp/g82f2Z7KaHeNzjrwWaRvSAaQjSN8i6dgxfD7G 50/sT8TOPiKlSLVIM5C2IR1A+hZJzz5CrrI/cooROYdrkRj7I3KVfYhhfYjczj4A9AH7oKeLvdNW VV2+VwDJ0iwQKcgC3mAWcHrKO9lv274vAkUlgGlQ1KtSHhlKKqS8toL+kU7J11azINLJ/tIeTUa2 Dytj75IUEkNP3sWb3yVRpAlIzUhLkXSA3gP0HmlF2oK0HSmFBCpDriJF2SGkt5HeI2VIGtIEJAM7 2obXdLIjbYnhkWEe9mv2JvFixg+zX4rr2+wNcX2L/UJcf4VrGPWH2Btt4QgZZkY9wXdUXFVcS1Gv sJ+35zsjPcMc7ABmMIK8FKkWaTzSDKTNSDp2gOW1zYk48ZBXySHwcIS1kS/F9VnylIFoCyNaYgQI MMqzxOBLACHbFt2WYFpi68O45Vni3vsB8Sxx5yZAPEvctAYQzxLXrgLEs8SchYB4lpg2AxDPEuOn AELWyZ54Jb8wUjV+EY0Os7PrMUvXY5auxyxdT2R2Pf+Q72Xex0fbiosxY49oyaLiSOs+2rqftk6i rU/R1rm09Tbauoa21tDWq2lrkraGaGuYtmq09VU6CFPRSrWOH9xWaz7aeoi27qCtLbQ1QVsLaGs+ bY3SKq2TxdouB9fhUicu7cM407FY+yVDIX3sLIYZjYHmY5AJB5AfQeoRdxoaRfMyjf1hfs1rL67N 3PcbXL5k2GXsdXzxdaDhdfIxkgwEvQ4yeh0PeR2PsyOvRZqB1IX0LVIPkg6t8zCOzSK3Iy9FqkWa gbQa6VsknejOt+gKI0uQ8y7uFB0rRV6LNJ7fsdfxycMnxmJarhpSk+pl0uYQtYfp+HBPmFURjwdy 2ekwODqpdc+/rN/9y0qMw4zsXraZ5AIRW7LXzW3f50Y66UNtiVcjw9z0QRKWQXW0miRoAa6DSIu4 H0BCBl5eSULsJVzL20JT8TV7W6Ikso/a+Lf2RL4PHY98GepkAL8IvRr5fbRTpm2R36HkpT2Rd0N3 RX5V2mlAyf5EJ8VlX1Q03RsaFNlxSDRdg4pH2iK38cueyK2hSyOLQqJibqbi6hbcafbIpMS0yGV4 3sjQrIjWgmfuidSGro7UZFoN4N/ZEylDF5IZsBidLQqJl8bD4oH1VZ10vlai36pv0I/XD9SX60v0 MX1En6sP6l0Gp0E12AwWg8lgMOgMsoEZiMHV2XNMS/JVz6UTi58OBE2JLGAVEoZyMYOcMGpg5AqS ypFGs9GTh9PRqa7ZZPSsaOr05HgnNU2cllLiw2nKOZqMnjI8NSg5ulPfMylVlRyd0k+4qmEXpfc2 ojTFNnRSMqWhk/bworXBlHNEw15CqWPtPUF+7bP2nsZG4vOsqvXVOoc6qkeN/A9ZsyhsHpm88Oe7 ACZ9ydzU1tGTG1Iv5jamyjnQk9s4OvWjydHpDXvp3+nJupF76d/4pbFhrzSU/r1uEi+Xho5sbBzd SaeKdiRK/4Z2oBhc0M6AhZm3I1FDONPukUy7Anwf7fL5Be2MRlIg2hUYjaKdTHm7XS35dSN35SND G2+UtIg2Ld7oxW0OFaBNATK08bSSQ6LNIU8rb5MaKh4TCqFJGBma0AAJiSYhGhBNRM93iSal2SZ3 nW9yl3iTlOmNaMMzPMZ6rLeN9RjaXDSR/zM4d3gySduHNM6eXjc3Xtccr5uL1Jy6e9V8X6p1VjS6 a3Yjr4impETzrNnz+XXm3FRjfO7I1Oz4yOiuIeJ7/1Y9nVcPiY/cRabXTWnYNV2bO7JtiDakLj5z ZGP7pRMqq37wrrvOv6tywn941wT+sEr+rkvF9/7tXVW8+lL+rir+rir+rku1S8W7iKDxCQ27DGR4 4wjgj1/bmdkEem0OxhqHe9SlQwXxDon5bgvug7byPDEnG1OW+PCUFYnTdd9hfYfxKvAUr7Kh2J6t 8t02JBbcR5/PVqkodsSHk+SKlS0ria9uwcjMvxb8oWjFSo6KTJ7kZf/xD03qUtrMkVy3Hp0qnjw6 VTtxWsMuvR6lzSMbUTa4t8xsruvs6coU9kPhYN5Qks435GU1vMxozDb877Qg+oRizM5eKBqvtlMt TFeQlkYpFR49hUEUTJmGaZg+rWEfdCm+SLQ0YoAtNElbep/GxyFgkikhGHZLb1qxMgtl52JF9iqa tiRJsqV3Snofl+STJTIxVyuSEG3KPuJHCijPEb+cID5Cej5H+oJf0wt6vuD1/Mq+gqDj1gtPsEnI DrqA7CAHyGv0JL61k+wlHYSrQCPJY+QW8mOyHsvaNJTcRSbho6D8x9Tf0wHL5EksmE+Sw2h7JbmN 7CMe6uv5kqwma6V38K21xEryyDAygSwh99AxPSvJdPKxfAepImPIdWQpbe1p6Lm35/6eZ8hPyF7p lz3dxEwCZDY+h3u+Uf7Q80fSF994gDxMPqb3G3cTDW9pRcvHyXLyiNQk0555PWfQgxi5Hn2QyVhy mHaxJJ4+l3xOffQWaQSe8nRPqucgWoVIE5lPHiH76AB6KYsp03vG9hwmHrzjBjz1YdJG9uDTSX5G PqAW5WTPMz0niZ+UkMsxng7ya9olpbvXpGsxYwpmqYhUo2YJ+S/yJjlK4/TnbIliUcoVTbmp513i Iv1JPXr7HL75Gf0Xuw2f1dIb8qie4TDy1pL7+GyTX5A/0wAtpePpVFbElrAnpOXEgDf2x2cOWYD5 fghP/xPIaA+zsCPS0/JL8lldbvpYjw0YSZBHyePk59SKkUZpC72dvkf/wkawGexR9on0Y/kF+bf6 mRj11WQxuYe8RP5FnXQQnUivovPpLXQ9vY8+TA/To/QLNoxNYYvYt9J8aZn0M3k4PpPlFvkOZZ1y t+6LdEP6YPo36X/1lPesIxNBD2vQ+wfIExjZXnKEvI/Px+QTqlAzteETpTFaT2/G5zZ6D32KPk9f oB14y1H6Cf0SS9I/6VmGlZbpWBDKD1eB4mw5NMwfs8fYEXyOsq/Z95JXypOS0gCpRmqUlqBX66Ut +OyW/iwH5CNyD+a5XNmqbFOeV15SXlNO6iz627HGv33u6e7i7j+lSXpDemu6Ld3R82fiBg6xesAE q0HvZ+KzEPjeCorbSd6hFsxdgBbToXQMZmYGXUiX0Rswk3fSR+hPRN9/Svdjln5Pv0WfrSwk+tyP DWDD2Xh8rmZz2TIoY/ezDvYeOyPpJbNkl9xSsXSp1CTNlVZIN0pbpZT0tvSR9Il0WjqHT49skiNy npyQk/Kl8gx5pfyE/Ln8uTJdeUv5VGfSLdat03Xq/gatZqh+gn6ivkm/Wb9H/66hGdT5OtlNXhFc m83oMWmNVCftJveyCtkPE+bXoOcZZI40loFS2fN0A7uVdrB85QbdEDaEjiMn5QTm+g22jZ1mQ6Sx dDSdTBay/pnH6Vzyi4Bq5NfJCXk/xvZrPPkGnYXexr7VWUgbdKRq6Ei/kMrkpPQW+UD6mOrlJ8mH sol66Qn2nDQBVPAzeajSQGLSY+Sn0jJ6K9nN6ggxnTVsAh2Poy9CLkyh5fQ7qQdq8DhQUZX0F3IH WcT+QE6AjzeQB+kceR65l1TQW8jn5FlwRZFyna5Y56a/YgvkjSyHdhAmv4DRVdN8Kikucidtkh7R fcveJyvJEdlE/iS9jN4fYT+VxsonlUl0PjjgVrKOLOtZQ25UGuTf0nlEolNJgXwM0u0WqVyO4boa UmU6ZNoecPc+yIFh0liU+EA5Y0AX9ZAQj+DzEOSEDApaAB6/ElLs16RDN4V1knmKjULqwFPzVnoS mdbzLHm4Zx65rud+0hfyYH3PLXji8+RTspk8T9embyZLYUq+D94eo4xiR5RRPX3ZRvY+m8y2/hC/ mO0C6iNf4fNTYGao8irZKP+eTCa1PZt6fgfq7gMJ+zCZBYX1OEb5Dd5wmdRFKtLj2K6eUdJSjPdj MrHnuZ4INZH5PdeS8WQ/+YleITP1SeA4RX+L8d5M5rJJPSukuekFmIfNmAUNs7US8ucubUT9lGFa 7dBLaoYMrh5UNaCyorx/WWm/viXJ4qI+hYmC/HheLBoJ54aCAb/P63G7cpwO1W6zWswmo0GvU2SJ UVJSFx/VHE0lmlNyIn7ZZX35fXwmCmZeVNCciqJo1A/bpKL8ezNR9YOWGlpe828ttUxL7XxLqkZr SE3fkmhdPJo6PDIe7aTTJjYAvmdkvDGaOiHgsQLeImAr4FgMX4jW+eaPjKZoc7QuNWrV/I11zSP7 ltBdZtOI+Ii5pr4lZJfJDNAMKOWNL91FvUOpAJi3bvAuRgxWDDEViI+sS/nj+CoeIxXUzZyTmjCx oW5kMBZr7FuSoiNmx2elCNeUkqIJGSFek9KNSOnFa6ILoOOkyN3RXSVdGzd1qmRWc9IyJz5n5vSG lDQTz6hLOZJ478iU96bjvgu3eDh0svUX1waljXW+BVHeeOPG9dHU9okNF303GONPaGzEM/BdVjCq eeMovHoTMDWa6+IptraxIUXX4pVQLAvEqDLjy2i9Bc0LoyljfHh8/saFzUBNYGOKTLox1hYIaHt7 jpFAXXTjlIZ4LFUbjDfOHBna5SIbJ93Y7tei/h/W9C3ZpToyE7vLZs8CFuvFwFxMeqZOQKI5h0ZP Oj+zlPcxfjk0wVR0dhQ9aYhjTIN4NncQ2Th7EBCAv0aKb6XmACMLUsYRzRvVwbwcQ6QppUCNRzf+ k4AC4ie+/mHJzGyJrkD9J+GVnE7Ok1qKzuyFU8lkqriYk4h+BHCKPg4V9wP6lqzqZPH4UhX2Mzca yATM7czGwaWY/liMI/juTo3Mwk2qdWJD5j5KZgXbiFYK3Zo185qu3hp3Pa9p7a05//XmOCi5g9uz xJ0yJM7/s6uenLr5g1PU8z9Uz83Uj54cHw3VOFq3sTlLtaOn/OAuU88nFPOGuiyUyhnRIAUZyjjE gpKozWjIvU2gLjdYUnIB/ukEUc/p1BtAlaKERkel1ObLMnmjKRbL8sz/9qXOnpP8W+Jy4WvZYaQG J7MdzXQ7NeQH9z/onmWjNHoKRA6DZr9xo+kHdSC1TC8vz15A8TD0Y9ERKVIPzizAP5gcg3hqDKY0 TBlqpoCLRHFjMHv7g4bB7Jca8ceps2/JKMjMjRtHxaOjNjZvnNnZ0zorHlXjG/ey19hrG5fWQdpl CKezZ9/dwdSoTY2Ysfl0MNiDkeG74nTDxF0a3TB5WsNeuDiiG6Y0tDHKRjQPb9yVj7qGvVFCNFHK eCkv5E2i/IaMphhkGzOI9sG9GiGtolYWBeJ+NrwboizTCGWUzO5kmTK1tx1DmZwp00QZHx+XMSOm NGTRIgiCsx5oCDs0eAzXMeQWcrk+l1xP15Np7EVyi0jV5EVch6F+X7ZNPdp9jFSDNBUpgMTLxiLN RIIeS+rRdq8ytadbmUq2Km+Sa5CeAPyUrposBvwM6g+g3Vbdi+Qh3D+G8tmofwLwk7hOl/9CyrKw UX8PbKypRIf2VyCtg1U7AddRSKPxnBxchyOtp2+SDUh34Jnr+T3SyOz1MoxhLb5Xi/b5KLsDcADP 5w4pO1KMubBGE0wEZ16CnS4dOYhrFPZLpgSqD+wZTBIsEfi58aeH3WAkJthPFthcNmLHvpGDOEkO tBS3aNGbeWCr+YROTEgQenGuqIBbG8+PQZcgJE7ySQGsi0LoFgR2zg//ikkSFkpf0g+aUhnslHJR XUEqyQAyEJbdINhFg8kQaNuXwLFfC02C/w0TOUQRcdMGVgLNeTNslLA0TJohPQgN+C/Kd7pP9Q8Y lhubjO2mbovXUmcNWD+z3WEvtN+lTlTfdYxy3J0Tzfmna7Pb6bnM+7j3lG+dXwvMCJaHHs3dGJ4T GRrNjb4ZO5B3X9wcvyv/yYI7E3MLL+3j7PNA8YLis8lDJe+X2sqi/cf0X46eQCXhRpyCjSjMHIk5 Yo4CZPAGknNRqeucppCzJCp38frLe/rKObphpBhjHUTf1QpuCVO5rGTgwNJRsfrYhNKmgQul2aU3 SdfHWkpvHrg+1lp670C1f2fPn14xV4ej0fzKEu54LInGKxcaBhV7LFVRT3FZzEzclqr+ZTHiroqV lR2yVLkslqoyS6xK9pbrOtkzeyYoVDlBQ/vYMyTIdrR7I+8kO+kAzeRye1q9XpdCijtpVRs1laO0 o+gdag3to4PQ9KG2AS0JSB7N5KwuS2iJ1oSU6GSTNHuxx+uNRKLRQYPKy4uK8O0faR7idrmSyf79 zWaTqQyYaiVHMQWdzKIZlX4tS9TVKlP30XuJjg7S7LXKeGW1slmRFX/1m3f7kuPUU01jT5xadgLX GvXCp/sCyKFTTckTp06Q2lMoP1VTyzO1+7j413Tc4fRWr7f1S6633XrQjr/+Zb4RN2pXxKosOfkF 8YK8AknnTNjsVjvTVcUGjKcVfZCV5PQbT8osyAYWDBpPY9GqQZWF5eNJRXlfRxLVyRxXqb0/mvS3 mAnvWDKbZa6Uu1CKk8Vr1gAiySbapAzoxwqrPF6P15EoTCQGVFYNrBpQ4eYF+kSi0OHxhpnbpdO7 JZ3O7fJ4cwYOHFCZKKTp9S/cbNrtHjBm4ZIVU5s2XNW+8PHpq3z71LkNG0qmLKz+5mcLF9w47+aF C+6aed87HY4rX9uUd9/IZjO7xD2s7MVru66f4Jw61T521kuhhcuc3d/n5RQsvL/+1TPGPbo+6oam 6bcUdHusj7XMur6Uk+r1PYd025R3wN9ecG0hbCO9Ztri3xJg8w2BYJDvyNh9fpfP5/cF3XZ/oH/S uZ9tI0aYJBa2TTNLAb9fokGfr6APL4+gvB/b1lZgDu1nj5Ak+KE/e6Q97+UBOn7vxr0djzRGIXBW Vl45zZdUTzcBjeppgcsT3Sf4lAKZNSpg6nBWV/O0vl/yVvVgBomTaEVROBkhFdH+Edo3Aag0H5CV 2SPEK7sj1GEClGMAVJzbBzsSMWQlhf0ipCyOzEYtEepRkKlmZ4S49MiynjP4Ynu9YGtoU07lwIpy 2B26eF6C5nH8VJRz9Ei0gtL/T931T2zduPuVdWt30eoRjdOGj0SS8u4/92f66RMPomI9KgbzwrrG afK0x//4iwP7fvUG/cWKR+9pWfHIvS1nWnTG7/9F733iQ17xJj244tFNK3gFJmua1E4L4WdTSEJz E0WiyjcQ1WuidAtldKFu2XOZmSS1mUnrX5YjgdKkDf0Ol+Gbzn/+M/0NnnJLeiJrBrZVcolmKrRj W9epN6hqJ61oJ9tsBlw1h36b7WoiqVJUkqSXHY9vEg/uPs1RRGqBmv5ltIkmmIMTc4VOj49bpfTj B349dtr+NTcWXhLHLKYn7qffUds3H3SfPdq4ceurP0tH0hzlF94/V7P0YX1UZjSplDiNvAembRLF tQP77lfboGl1qCqrB/Bdh90ugOMdVqsAvtbsJhOrt9siNmZ72ZntI8fdv/UzJ04clYXgvcIKMJ1b Zd2cN/MuKbxpzf5pY4+kJ9Jj9M/7927dOO23Z7s/+Cb997QBvXwx/Sd6B/x+JjJutwmC/CVdJ52g JahUwxg10Rpiwqa6VEN0g/SDx8MnsgQW/nZgZrv5yYcwW6eaTh1XT4CEgQxByGqGkvuXVQAlYPfC gQOr9hyecGV59UDp8OFldyfG+mdehfcOo51sIVuMtaFE8y9lSyU2lo7FK+OEBZSlaOCXl97D5ePx JvUzUjr2RP8ysgyEOiDmHsaKaOfu3Xxt34dsPXovkQLNx3hnazJd3Enk7ajfLotenm5qAj7xCN6p fYcPH+bfhT+XVYM+JDJ5L5F6/tTmqmZYcbSoq/pBiTJpm7QTAQWrCHWhNRY7iZikLwj7Anh7AS+X 22/C+CGJT6gZWlmv9Es2Cc6lTcmkm3POC1vSDX7l6zN4AiP1PZ/LDqUL9JhL63cxrrxppkBYVlxh q9Vr7Oz5QuCeA5qfI9/oIBZODcRjsSC38DJSCsQfRnYY4+EjCu7S/fcnncKTdPV40megIgF8o/nN ZkAOovISolosPOdl5x954ZkduqhfDYEsocqa/wvGpwfJiWTHKjxL1q1nG8wb7L+yKUa92cfqcsa4 r/CPCE7Jme6e7p8UXKRfZJ6dc617kb85eCO7XrfKfJN9ve4h/Vb1V74P2Hu698wf2gPnB95i1GLx yjIjJUbVyIxbIo4WwpdeG0qjWE4Z2RLmKyVkZxJ82bQsyVHJh06blkGZG8T/KFJjY47q5GLM4wTx Q5IVJnJULsccaiKep9fVL3pn+6q2FcMXvvPkuzfet/eFW2554YXbbrmiib1DZXrJyzPa0z0fpNPp 13c89Ap9PP3gtyfh4V34zYJ1nFY+BgLPAncmslOLSprVUblIXg3t62EDQoqokegUJhkVamH0kEn0 3sTHRGgU34XmIrgbwFeaQyA0JBBqEwjFLGt+jq5enAj8BCyKZrVXKr0zUabQKLziTPGb99EaupZk WGNZEvOSleOYmZqx3WDEWm81dVTz+SFNyVjcodPpB4ALK9jZjmHvTHnwk9IV8s1Db4n89NJDM/jY akDLeowtTN/M0pLRoVp9OTm6emtnz6kOh0MA32hGVQUUdilhTqJe3iAc5rXhkA01YRAo8k72qmZh Jq8XEUgOxqIRrGml7x7m+WFSeoJ3tpbnB+ECC2bZgL/Q4nQy8ULNaHcAyrznmGZ25rD6sIuX8We3 4dGcVcxmVg/ga03M4n96G+cR/j7+NvEybeAQZYjuVeWA7lX9m4ZfhfSXWxotU2yLLHNsNzlvyrnL ud/5aeDT4MmA5YD5lRwWREBBrhpWdf+FLQw9iN+AqxHYCoRNqkGnOxQKuEKhgCEUgLQwBEKSNaxC 6Wwf76AIN/Dt5iMgYjrslFlMLd53MNuc1umrbA2JEhX6oMWxuxZbDUvYaiazfSwfOsXmXRli53pC kosXLETdNbUnujOKHtSEjLZng6jhOgPkYi8HDCLQw5Y3Nha4Y4kqYFxoWPE8IYQzyzsWMJ1e1p+r Yt6Cpx/59vmHb779Mbo357vfvHP6sudee2p6eMeOYTWzu247+Ok1i3702MacI+9/taPhxf3PbJjZ H5Qytecz2QNKSdLGLOLMfp/GqdgXIpSTatKCG1oUN1ntFnvYZCpyh0NyuCikFFnjVovPj+UvCtHD 6qN66NdfdPDmiVIu0A6X8g9xVtfWqpCooJYTb6hvOKvVg8lynkAsWh/F6rHWWddZ5TrHlY5VQWmS 51p1oWuOZ6X1Rtc660bXXcGfWE1KVOLGgtlssdpkPcV7sdQ8065hAK/CCVxErFD2LRa37ON2gZ/N 1wrRSwXdtDpbZkSXRFnUxyk52qpvSQjZlKAkoSYYenzqFV6T2NLX10kHtfnfodxeIBi4+YK0Kumk 92dxyJV2YJHLrFNJsQQBj9DXMThV4BOMCnSCVSHCwK10WWNOlSere0FmVZ0He3HIdTS9BzmBpja1 I/LAotU7n7q1YozLaW7pXLdwwSZXR+yrn95waNE1c27fkv7ivZ/30Dt8D69P3X7Lk64n2A23zr79 zjuju9+c1zZnxmP9wj+7tyv9z88gYgOQASo0LhMmJ6ENdDZY5lsesbxg+ZVFGSONsf5YlpygcWLR SXrFZJb0xAJmPyTJLkmSJSthFqusl15FEJYBZuF2zURkGU3IIZPcya55RVFMWm6k0tQrCQHwhYnV A/hGrFAm2GGaVa/lxSv1rbEB+i12LMWYVaurkjAV/hQJ98fEdwAc38OxwHbbOukmMdNfJ5NNQhCe 4uKlRv1MFXIQVtLpGkc1n2ShVstgGWEfUbEHbcWa76yGjHtXM1dUS3l9qyU5N7eGP6IRyEAbzWXR zNWW1gnVFi1RbckL4dq3mjdINsLUHUArHBXuuENyULa1+072+I/eeKMjPYDO+Im059wVP0k/CaZ+ oHsRCI+v/THlWcjYqRnOQewKxmflk0BDNlPY7Q45ueQ022U5HLLaKNH7sF4IjUAAgsv4us+5hK9/ IKLug+AMzhhFTiF77SIfHbgxd2Pu1pzncl63vGf5MGgw5vhsxQHJWKaUmfdBjkngDjXH5Hbm5Byy 2V22HBeMQ7CIlsM7otm2Q9G02TU3zXbqFbtM3+HsA6mmRXn3HDNUbtduVmUVTOITTOKjxKf6GDqb YRLflqhzPx2AOM0HQFSD2my7/xOzIHzqYma5wC5NXKMEj4iBNjmqS5sgFo6vN/RLKsAiEYKPr/qD 6DJoWz9gG/BKTswdk6ALwDbXc5um/mfuh6+9vWPHpis39XnhXvZ+9yvj77yvixpW3HPql920Vd14 98GnHmkbX+thf3s5vWp6+vRv3ryv7RjX2sYCc27IvFxSTMdnpV7ETiPY5oQp2CesWanViiUxqOSF XVZTmJICFVOQ0eDUsFflC75XyDwv0AM4q8Edfvew+oteTDadUA82cUz2XeSnI/Wae6R/ZHSac0p0 kTRHP8ew0DknusKwMrTWsC70nuFdj0Mf5RxQmOEJXX1cCDxeFBMVel5RGI1HY7zCwXs5wcrQzyB9 ZwZHJISesbfP0GcHaU6yu6BFFYiEjaLCGsEoTr7CtUR1S4mJi7kwrdY8td4Z3iXe1V7ZC6VUV+/1 8Jd6O1l+ezKjpIETT5yXeRlNLSPpSpu4ysYxxtmHS7tGqoe1wlUznX4gkOWEbAOyiEOtwp2Hui5I Qp10tt1XcvmiqcPqZ7Fh++d1dF9/9M4/p48/ftcXOz7qrhp/77jlzzx1800vypNtC8vGlg395o+z m9P/+u3GE7dha/YW+sLPn3/t3EdNLzZ2PvHQzp2YgJmQdx5EeFjJUs120Epl/GMG2QhZxrmwjFHZ aLG2SBLjUzJeLNESC9gNLca/kvHA/Qwm1eKyhK6G8uiHIBJUzL05y2rGnjoxTj3NtTFuGfDVu9oh ZBDGv0xYMDoi6fTxgU5n1Uxp96b0idED7Xul2/9xl3xmx6YH0s702c4Pd9Cv6JuPcd/ZZFCgHxTo hU+xjJEMDXZYSDDcj8tI6GGsvl8/ZyysU/qEndaw0cIXWCj/pyAmASTt3L7kZAggozhxQFTafVgr M8anAHgrAFnylfLdFq5nucUT3YJ83VnyzVghF5kikEfJE9VYy7IWySuiI8L44B0BwDtyXFgmHBBl 2fdz9RevPafl8Yb8tZy4+At5zkd6YXy9LIN3USEPMz0RNhHnoKoBHlrkudxzeeIzy5dlirEMm+e3 0lvkFYZl5uWWldabvHeTjXSTvM6wxnynZZ31Hu/bjjdynHnglLZQNMAv0Wgpv/SNYsU/poWLohYS 9hELurG9H73Qk3DLASM1drJ5mppssWtwTpbBy2BX7czeSe/bU+5rScF0Rn1bfou7V5GPujU3c2/p f96kOQXeB9VAQ8gqCM7qplI+OL5oZTlGyLmm5cvIssZGyn1rnD8u0gQISnJ6fTZQ+KSLWYcuXHrt Zwe6vlq0eP096dPvv58+fd+sdYvmr73rmnkbBl++ZfKa53fcvvo5KVj00MLtH3y8/ZoHi0oObtjf Qyjt2vxzOmX+nXfMmL3+znM9Y7eMf7b19hef77VlOU2GIRV/mrEaXjFHsAQUOLAAnBZI5iuBWNwB nNT6cIz6HAKlDmF9OnyOkqS5T5h7NsbbJJvNRSZQKtRIqwqrgvKVBkJVERg/mGwqB4k1nSgXEwPM c0JUuRT96Bec6IRBfVEnLqydWrFYPB2Civ8/b/3hu/7tVXjThRdplYMDYzxa/CrPlfFrpGs9iwPz 4jcFbg1vCtwdfsTzQmB/4CvPZ9HT0ZxLPE94dnikwUVzdKyQr7txEJMvFtVF+4TH22bwRTbEh0ff mZARyR28EwgkriZmSGTHD5fVLSVcTndwMe04T0sOzcEcW7KSV7iIMwYyl7vn185esUua4D+BkSwU zKFsQGUhl7a4wufrQbwBN5kTtBICOev/W7rDc8vMybdOGEgHvrp4zzmqf2PziZtv+ttTL3/A3vrJ ihvaXrjl1ifpZPWm68as/sNSi2/qImr4w8dUfST9F/iWPk+3//SAVPnonoOPbYLIxUq6F+bPOkTU 8d2CQdAjsOuiNzJdjSzVUJ0Mzw30GsKimIsnDVnf0jIuP2ENCJQLdsjhjj6kvXDiSI2HD597Ds4c hpg3ojRCf9XD5TlvD7XZ4U2Dovj3jizwnSBElJzSGjkhchmpq1dEXqqWqfMM843N6gZpi/or5Q1d l3pSNRuURgSUTVDnm1PqPyz/sP7DZpQtslW2SQjKUGQZ1oVBp9dbABsQOQV/Erx3ml1Y9lG9xYUq JkGofadBmkGqRmWLC98yhhXFENZJ2J9YqhlxvuhLDTuKbB81g+HMmtMSJXP10qQJCND6WJa2yFRG xLZmnmDp0n9skbZYqIXfq3b9ET1brW/VM/2P7O/9XnjilvkhR/DPhxkL+NUTJ4ivtiZwovY4/Mv4 x/1T3LO8vh+Cn7PGIxam6vXqwYO2gwfXK5krRM7olBnxnGFsWnfIdsmg3wfDl/R8x6VQI13O9S3+ F4eHKy7FpJyYlCjU6SVW8RvW8NFL3Y8++T7928Oj8kIVyr4zo+j+9Eg2jW7de/09d/PVbCtW3i+B KYfQqHL2Ehk4uZT7oWR5VHxq/Jp4i/FOo25BYKWy1NhivkO5w6wr9BglX2Fx2JNrNOY4w8XFRUUk lBvGvEXggCAGX0Jn4f5THewKrYKvYTonZ3mdjs+8zsCfDhAY17n4kqKbUpCwhPg3LCbezsLpws1b WQIlueGocNtEeT1wyoVZFuBtUXIG1uN5AH4bLt7wHEBNySHTuacqM0FNWPmhCOAGOzyZIu674tY8 EoQZ9nBqqksd3OtPM2Yg99hUOGLwYfVKdxuL01h5xpRPxGF0lFdx3k0A3soSz7/Vcs28tZuvbP35 pvSP6CVrBl0xetTtT6Q/pIuvToyYNnjKA5vSO5R9jXvnXv1sReH+1nm7mvtLkxyea8ZevqTo7Ha9 ZdCiUZNuRNgaJdf0fK6sgjc0l7yzezZbmMsgiLmyIMb3hTaDQ1FSbp2NmKsVua3kztwt5BHlJekn 1r1Sh/VN61FyPPcfuQ6bM9eRmysV6/o4ikPRyKXWqa4r3VP985VFuTc773Y+Ij1seyT0PH2GPe/4 nY3vqwZUlxqQwZl/autTLYR/3z7Vqp1QOZgTtkjBsGxUE/YrSCKKtSEQ8SaiBmqAVqKrN/jDszHb 0LmS2ELDRPONNC75ak84hE0NVZR7CKFsLqdenRzPy8fEOfMrymW+IwUxh/0opwcOQrnjtUvSr396 Iv37R3fSEa/9kZYMOVDx2o9e+Mv0xZ+te/oTxvp/e/bn9Lrffgq/7bG3+m6//6n0t/e9mv5yIzaY GWI4iTINFG3H3H2qlUYjdIQhQ50ONWwnBnTZSCPCTWIURGU0cYoywsmQUdO4gIBICkRy1f8z6f0L NChQ810v6YX/nfSyZMi1iizJ9S/DvuBAKajHeQ4FJzpknd8X8DGd2QQ+MEk6t8flyfFIuqDkjVGn DZnPEIpRj8kRw64RNhOK8YfdIk6h2NaDn9XFQJ8FsfKsr6kQVPkE/f6labc1rmgZd9N9h9emsTt0 30/614198NpxO9JvK/vcuWNmpY8cfC6dfmFm+Y6B/eu+fPazfxXzk45PQTLw6GozeUBz65SwwaDX E0nmbG4yhs3EAKumC8d8nJX6KdIVUVPUykwBq2z8P88Z59sfsqtlyFUZAhLc2cTdp4KOTh1Pnp+0 LJ9i78ABozKbnpLzzz0hJc/9TrpT2bcjXfty2rqDc9FicNFecFEBzdECQVfQzZoL6dWGHOqU8vNJ zOllBQQD4gOJ8s5QqvOGbRJ0dyOlicKCfGxERVm0sFk4PLiynF3HOK2AST4QokesY0H+fba8tZAW 5iaiJmoSSpXJn5idHRPYYazaJGQRRgZRAzFz3nWQBEngnkseJO5FBGmMlOPBUCDkD0k6S0ItcCci CUMBgg0LfNbcGPHYc2Jo7MqJ6nGXpxTEaMgMGnE5kIWNsRjJl5CJ/UXQitguzko97BML99aAAscP +BBbw/0YGJHvq7mcMlixyiGNYYs3p49u/0N6W0c7nfDhNkrvT+yMzdqzZO1r18cGrafsvttODmW1 L9PuY8tb9tKr//AebemY1/njsqWtYyfeOX7DtoPp71pnVlEH8PEMeDNP0NQf9hIrZj2Q466UpbDR tN101MRMCmNmA3ghqtdj8fhGzDeAv8PzhAnXCbMd99DbuMTRUT7nuqZW2PzMnKE7jkoTHkr+h/VC M4sFQ6xDWC0u4l1PZtmwRK00ChO92brUKg9p9MFj2LuIQIgBVVk8wrXFHVtYP2AjoBhrNZYLECZS HPkzr7Ezr73WrVP2dT/Lpp0Zxdq7x2IWDoA012AWJPL2borASsa3FdoHXSK2F9orKjPXvmWZa5+i zDVekLnmhjNXX0BcoU2rlVFli7JTAa1C7dmM/cAUkUuxVzMBGyUnieKMonALkcTuhZhJuIYyq+nX vasp9/tlllVNzDKJirXmKfk9DL938NwH19YKxaipcdnymu6s4gEPH9RCzpAVjgOvcSUDY+R6RTHG qJDFmoUy4FghhihXn9hzml3P0NUomv0PWOpd1U/3ionzolX330TrZ00Z+ZDpRMy99TX2W3TkHzvw iocQf2VHT1R2vNfXZ+g5naEBg82KfQzwL4YPABP0jdaHQxYnJxHFbpFw2JwZjGYbMRiZyazj82bG nh1yaB57eCuzCiL6rHdPKbNjjJJzmRnlZhE3hvluXm1Xl3r0aBf3MSNCBcSCWI3eDcOIXsy4TuSS yGWRKyI3cC6Ic5wwsdpCJHB5Y+N5Rns2CY0KQjmjXOML32kRTs8JbIRFTc5Ku8gUi0SoDeLbADnO B86fKQD+KNOrbCoirFQ2VbMS8SIiXoTxZB5LuJGfPFUKBUoQPqQWHwycZXw04i8T0RDUVhNmN7hY 0CCvsqyz/BJTabnccrldKpILrCW2BukqeZX1Btt6q8HMFEO1daBtPBstwdlmGGsdbjM9xB6Wtuq3 Gp6XntPrnMxus5UpzKUozACbtUwxADRYJtknUQ3qusFgNJlB2TYbfiLAyJqdrU7m3Meeh6ezf5sS RXBBf81kMZqimmW1mZr3YZA2akYN64SSb4SbIGpfqlLsF019Jao0K60KmIU93+7gzO/nu+pNNT6w vdDjAQfO3xxvglZfW8P32s9/AtD1uXa//lah3OOCTaELSvzPiKXnLHav3oOh9J7Q4UenLFDw+0DB 51Lxu102E9fss07xd/fEqm0lMeEY31NVbSuvEuDuvijNOr+TjbACyDLsNjU2QvpQj3dgFY1BBOEI j+MhnCe4qszjhx+cKq+mp+5MNyj7zv79vssmPCqdOzNKfuvsAPnYWc6McG8pEXCKkd66ywnyzkhS g8/iEV6oL7QYhwwwo6J6AwwqA9NLksEoM2bUG2QpqtOBgTISBUBWaCsZToKY1QKc1JSmqJlGzRPM zeal5lazYjZAYwB5wfsOsf2/yISs5JaFbPqB5M4q/CaOsF5xhU0IIauXZbchsrIahiv2Y6vXywJD GW8Jjzg49orFUWmIIgMFN/Yv4yoWcNBh0EZVw3Ds2jOq2qCVZ8Dyan2eX8Qn7PEDLM+AvDSeiVow x6v1NhdSDr8/tScHYG4GzAXo5uB3u9yZzQuhzHHeEawDFFZQvoJQx2NvSmzfm+fSQNgaeTWQ1Xq2 leu4s6HXfKS8i5jIIDmkTQjYqUt1uYLeYFCWVdll9pqD8gvePbY3bJLX6wuyaK7mGJ8z3qsFGpQG 45VqvWNGzjTvDN/UwJXBu70PM9UfliRn2Gx0J6J6ChnyhRBnADLrAoCTQh4D+EpIDAAZbxKAMyAM yA59oDWX5toTHIc6gaGM6PCHeu2CjGGQ0YEgM8ZmrAOIDm4XwDjIUUmsXOZqrLAOqlS4QhBEw2Ac kNl0Ax34Fh31Ukd6z4Ej6X3P/5Lm/v5DGrzxy/t+nf49O0QX08dfS//kjx+nt+/+JZ32X+l/pY/Q Shpsp+YfpT/N2AVyN6jbSnykTSuZ61jkYqPV0a6r1KtcstkCv5eNeH1cvSUGZ8IAggKti4gMiNJT mtDvDIFogOJfwGf9X9evLK1mhGjGSv2htuu/eBkTasU4dZmYHD4xvTap0Cpghwoln4fssVjMAYVf ROtx/Z4V3T/22vsbv0n/Kr2B3rz/iaYx/e9M36Xssznn7ln8arq7+2WJblo9/Q63lVPOk+BxmKCY gzx6Tos5zTbqHBiaFrnGsDgC046vFwaR60WeD7oXiBehB3y148a5KIGAyADOzp5P2p2BSlxPtucV VsIf9kl7bmEldizEFd5lcUX9H9pzE5l6tBf1uPJ67XIABbYrQldEJ5unhxaHlhtvsN1oX2vaYH/Q +oK90/6F7XO7itUu6rC7HA67w24xOnHWLuAx6eArs1oUn9Ho8Qb8YQQhdGWCa7xeEssT+PT57Hab IZywPQblMRPWA+C0WKCFOpnHR6bT8dHrmqL5S/Nb86X8PN//FccZav9P8ig+5PmLLBogGSZNVnn0 H/dxU5AvG1lcJ1EHBwQWVAqLmYeQ8r01zh6ZhTWbcyEhdkNNBs1ebVcHO5yDUdRIl4kVw4aYqYC/ 2gH55ESyaaFqNc+FFEE6L3D4OtHr1oDtmBOXEC6aiMcFaXHaiseeZBsPvn3ToXfG9qkf03Pqtfrr ruwbG/1n+uTareMefDpdpuwb/8sbH3svtyB/3Mr0Mtr/zk2DzPrulVJF1Y2XzhdROtOxU/JXWF9l zK0VzpZmyy3SClkuKBwgVYdGSJfrx+TWRUbmjyqcLDXqp+de2eeuHFucOwm5jgXCywAFvUCiFyjs BdAYOMw0zgBonAHQOAOg8WltFG/Ux5rIZ/lSYcFAO86UF9SVTotOjdcXXGteaF1ku8Y113ej+Sbr TfZb1ZX5LQXrpI3mu6wb7feoa/PvKLjfutW+1R3OhuP0jSWcwUTAmCiiCYSSB5xyef8EDucyYu17 Y/CuIAsWeKx9w4UFtEDxYCE8pWW8m+G+xnDYIwmPSBJWXlPG4OOXJhhyXkQhZD7YdizIt1nNSgx+ iyAOnOG8mY4W5OehDIZ4sG8AT2T1myGHTuCkrzBfxSqr0iidQJvpUkRm6uCfTmk5ffkrFbwaPb7C mCBFtIiLcJuN1QM4pVn5k4oC5RgTTYBDvxZVADB9EIAAsk5UbH5Crvv7Z83ZprHHQXPwbAqP2gVX D+IokgiEbkqe4iMCGWN0wpuGBRUe7ywJ4wKZn1MVZrAxM5Isv1BspPCdFBGhLNzeXg82NrnvDb7w /MT0V6wzfnnrkhcnT5g+JH3txAXzbvv7j5/+fp2yz77jhdST1YPo+w2tN607+/ib6X88TH+vXnfP lcNbRtbNi3tnJquenrvk53MWvL3Gdve9a64aX1GxqM+Q3atWHmlZ8SXBsMpgreyDVNTjbKBVYWFM OPwbOOiH7aSWdmG2UPqKLkpZKd9ConQ3FeYLpIlmFqaUIeuV/LuQjdBnPuk1qM6hRAj+NEo4gCca 9jx8QU1pQlQRUvfxps+4MMiIfoTRO2IIrow5WE46V96YDirWHTvO/IP39kms/tyKdpH3NVPC3iA3 GH5lkD1c8HmgQ1XKQwyj5CsMq+zPKl/Y9RbCHNhE7dAZXQkoHRn9DEBWP2PC3MP9MS3EF23WFPXQ qGeChzV7lnpa8dNPVuHO4E/nhrVJmGwwGDKOWAFwSgFwJrPkmYR6hvuMYQ0ga7mZmtxcPeMewuxf E3eJNC0TTpGMNiBCfJMIvalwZLWAAVCFMvtnDrn5tTnps+/+On1m6WuX7rj1vT3KvnO7Pkqfe/pe av1SGn+u7cDuWa+J+FCcGyHKKMyRiQ7NRgk4FQpTm6/uJqIYDQplSulH2K067KiowJzXglD5fmV+ qUKLSR+pwFRqKbM0W+4y3GXcYumynLSYo5YJFoSQmA0su8VmpAjGhx2Fr4stEXzbZDRGDYoLTgyY yVGmuBhTjHjVl1ETLJO5BjqXQZ1AKE2f6gkG2mrYgt9x4TsIVqb1qZ7B6GacYWawSqjmiCoTFFYG a2SL0qWcVBRYJBvazc1YULhFsuw4uIknH4/PwkIS8J/A/gK3O7KbCnxPIWN1uGBZtBE7MPG3NqMT 8uJvbTDMoNzB+sBfI5r1gQEyUBggCJ9C7KZQynhQQAzbCsKeqKBsWPcvf0tv7RfJ60s3vdENU//s 71uX3nCDXASTnwsHHNlZxXUL+qGWKCIJR5Ez4asmAx3VzoG+y8mljsudl/oayJWOBueVPvUhw0P2 7ERqFSoN+JPuSqXSMlIZaRntnqJMsVzlnqPMsSxyr1BWWG522xU3t1ydOBFvxxkuMekCa14hPaur g1pYkmEf6vSYfBNcPEarzW634OyuE6cefD5s+da040cOovxqcTr4VZvmhvmB37diUfyEDkXIjGIw hN0+l9vtc1qMxrDbCdDpQNxvVHW4VNXhNFoMPrdix54pYeiSIvkQUmI0GgwIlmY+p9OBDZCA1xtQ hxnpRBIlFuRuJI0odOKeKHeb+/2d9O5dGcWgKeAf2w1zsjvg7/aNq5s78rPzOkGvQcn1AQhRLkhF guky9mLjkm8gXTA1wVnrbdg6QlbDMwFdnAHZdiDbwWnCaeLbwxkKKEBh8QUKyBqsNpS0WzRFQyNO FMubQBA5GYLIccLOzMGuE1ylOj2lT6RvfvPj/MAgnJv/6rfj46G+n72evu7V9FuFeq8r/Svwau2D D/w1X/pTdyD99T/u7pB+CoOmaVN07qVnnwb16LIca6EL9xiMgyV5CGImPm93eivBMJ9rNgCyH5nE M1T9od0X41V/0IYAkPsgcybkIkOxqdQmz6fzdfPNf9LJOKst6Qx6o05n1ElGkwWKgDFqMrtM8OVI OiPsutOah5fCz0vBrFRnMevwy3WEmjuZXzOaTEaJQWbYOplPM1qMkzRTKxyVnXS3ZkVIY5RIk/ix L86yuzU4jQmIJOtHM4slQURpiPWAr7SQ/r49VttrMc7GSSH3uPRH+GHmAuzDmQBY+FWAdpw+SRrA yYrYJuTQer45qCIbnfICZSEgqMNgMVrkfT2nYMWeEjE9YrWlQks0GqEFGpBkbOrs8nOLszErfpPJ mOMCezvYkO63vqaxCXXDr6ahT7pfYYulselRt9zSsoXuPNfe/SNuP1zR84UckofiFF0V66uVGK3G Yr81UFxkLS6GC8ddFRxcfHlxk7WpeKF1QXFz2UbruqJHPI8GXrC6+/RuYEElQ0Q9X2ue9b/YZ4// 1T4H/Uf6/Nb9UR/DSA9FMPMpDbEBunondJreTeEBfH2q5/cRb8SXLCmurJarSy6XLyuZamhMXmNY kFxlWY/wyO+t3ycdVZU2Kqul+ZXe8pjLN6NoSRErCpXaam2bbdtsPTZlm22n7VtEOIhofhzy+Epo nACw68hjqm0iKsKm42EwCAqQEE/14h7fA4gu1gORp7SAWNDrCk3lIclcNFOdSWA5ALcFMWitX/eq r19nnNb5Msc7Ko6LGGkAp4QBDeCPXHfQ1eeLF+E+oynkd7KrNFuhxmNco4myxM6EUo0VQ+hlUGvf 28N1t0R/XqZZwwhyqe6qZturaTUsn1PaMP5Eb4EvrzT/gO6IjkV0tTqmgyCEfSNIUefj/QGVI5CI 57B4ELKNXOxX6PoPuuA9WYb9u6SKJQZ0ioNSvURT05389FOuxR5HLHcmfFZUNS07sQwCissooc5y hY9XiIhAsqyAK3E8VgabU/yDgAe+6acvHAolEDqfx82PocUTCMWywczlG4FoJNXM2btw5/5LWy4b sOiDebSibsPqG3NTvuuO3rXhxQmq0Zu3P+SddXDJ9PLFC+Y/lci9o37US2vHrRnnslkD+QWm6/pe 0rjMt+zu0drMK/rdcPLs2ksG0Y/6hNQ+Y0sva75q/CXXg6LXgaK514ufA2nVHqWKxZ6vDFDqFKU2 koqwSAQ756HhoaWRLRHd4JwaTw3CTcYEmgxN1gZ7k+fqwELDtdb59us81wW6Iu9bPvB+4P8k52vv 1/6/5B6L9ET8UaXUXuoqU2rtmjLGPkG5Rvkg95/yGdWium2yjpFgCKLT5A7ZzL78o2YcDNPgGWs1 y5kdSrOgUbPYm4TBzX3hwvN8UtCQMME5lQI4JtRMXqKVcnyaV8CHRATxEVkonhVSAWNdFLbBdpqi J6kcobX4lR4cfOpJC6IFcE7L5eRFBalQoRpSJycVaDogFbT4Dk0FcE7z8FdT0BNyF38F9YcvrfqB ggfCwU4BdrtAPTALekkIpMIJCP/EbjunFNgDy8kyHI+ocMAGgKNDRUh1oeTyckLg9miejvZ9rmP5 rlk7l2npv/9s/yJWWX/fqpd/snLVy9hf+efm8ZsPtaS/Tb/3ON16oP7uw28dfeMwVpUJPV9IJyCv AnRaVg+stK22U7uZ8u2RpdiDkZ0hs94XkvFLP269gY9eL0avh9UGGB4g5NzpnTz87hvCeENsKGLg m0QM/KVGC42ERuSM8E7Omextzmn2PsoelR6xPqM+E7AYrH7TQrZAWqistCy1tlqftew27jHttlg8 cIj/hUm2vBn2JfbVdsmOkPgXtRv5cdUJpBnd2oJNnGPYuzESu90M46S3jyF0Pd9m4JNtywtifPnm ZASrDrQKTSBIE9i5TOAkIHByecidf0RPI/paBKfYeCO9iTfSC/Gq7x+sPJi1RYCVDPM3Lc8eYxdh 0YMaTyw/lTyxXIwde5YI/lWbjuOfsOiAt0Zs54O34akT532yu/kZFpZqduV++9MP0v9a/uVdO/4Y 2elfPW3Di8/cufBeutb7yhGaS00vU7Zm55PBRde+/s57r93O15hRwNnH4EjEpNB67RkTk60F1krr SKsywDUgdCWbYprkmhyax+Yoc42zXc2hrsi7yu9yPvJ/mvOp61vvX/2fCs7zRCLJAGfX0QHOu9jZ zLf28wxmA6yjWZ11lOvy0JWmqdZ51k91n3vO0FM2lbolmxmhDkHQg4OAJSWzr4KH0NkLVPWog6oI 72p2tDrAmpwmMgzqcPL1Hi4vLFpcyDp0nIIcgmFRCiOLz7jDxmcc998ILgXwnTacY8exwpl/ALFD H+t79DJH0Xi9pA8LkhNyWo+zaJwgBdrEsqQXq4/eH66ccBGnNS0be+I8d3Gmw14FdIrjHGc4rFKL sHvIZcFnfKcgNoDLYgjjDMLAc4juPc9n0qC5B1f/buXCd+9o3lra3h19eeWqnzx/8w1Prnti09mn t1Fp48RhzIbdTOfbh37+xgdv4xg/I6MhRcPgMzdwNlnzRkjIDZ2qSWky1pvnSouUJca5ZgNUcH6O UszEcW0Sh3JDPC90vq+ccZ0OyP2dg/39Q8OcYwPDQhOdOL0WmulcHJgZukF3g/s0O+1T8WNsdqvX O8HDrVPJE7JvUbcjOFqVgyGTHr+g8CIP5O+VZl3gBsw7jojSB3LA4V4Nbsw/CsMcQOaoA4CvBFIA dGnGwuLKFLaTAxHctRckKvlVG8aX2QiNeCrUfL2WX1zZiylszQE7GUxhIIAzDIYDZWAwsZvMMXWx TGxKju0+DkcvtD/hDRFmL99KzYbW13QvqxHGJEeXODLGV1AeMSNYLOMSd+ljIhibxkTEtk66el/J N3u/TH9LXX/8HX6v7NwXpra1szd1f8AmWgZNveuWF+hU79MdiJKX8ONgfdJ/Sn+vRnfum08fWDdi /rOQIjlAYSs8dV5q1cIuI7X7S/1lfhwE9T9qecz6gtUQsPaxpvxdftnP56NPIFKZa7BKFnvIRN0s 6cqR8QvQpm0u6urJ0WRvgYxfwbofYolPYv9BlfyqJUORyi2E+jXOJn7NCjbJKst9hKKcxxmHlAhN SjAOF7/ExSkf3+c6mgA+w461AM6IaHjytM+/n+4jMXIavwXVq1Nn1xnMKlel1RpYyCewRcxVa352 C2F2IsDChbhWo15ngIakwp1MHDp7EL/nlTlGDz5Zjk2YARX86DyWJIg17pNy8xMmbdu25QTuWDVm enBQ+aSRR45Ij2xatqhy1JXOx02jmmdtOncNOGJ4eqL0FTiCx+Qu0ZrNZsVVYi5wjTHXuXTGXH9u iTnhKolXmwe6rjCPck3VN5jnm8+Y/um29YuXFA6NDy0cU7ilZHuJfmBsYFFtySjzqFhd0ZTYlKIF +tmx2UXNJa0lHxR+Efsm/m2hw+vRuTvZro4+oRy9WEnUKFxafB1pJV34+QOorexWrVwJheymuryQ xeRxVxRUmAp8vqNeqno1b7O31SuXwH3D6ktEZJRXiDWhUQqx5hVijR8vEMf8vsqINd6KHzfIijUA 57QrOD97V9hpAcmL5B+wH7F/bO+xyxF7rX08FjrBMXbIMIS/I7ocufA6ZY7K8HJdvd2fLFkR4+It OS6rdHLxhrMo/ybhuo+f5qdSwDgiuPZ45nw4tpKWeXk4lFAgC8E1PMyMI3AAHEmcixIXx2Zfs9Nc PmLFrRt8Nroq9eHJ635zz/6bnp374fb/+urhZ2+95fkdN93wfENgYkH5nGlVqbtpzUcPUbrpodZz C787csNLUvFvug68/fobr3Pvx3qEU/J4KReduRcHdLva3bBVudki1OsCeQB+0W6fVRZFg73+Sq/B YXG4JHil7CFF70LQV4FRqxhY2WOkXUbqwQyzeg8EGAzWPiJ3cQaB4fu15uATh/BXTKIRm6qiFBEN nFWMLo4StPqOmx+AENwm7k8jVgHAOOEm9FYOrEx5TnrYUs92T8rT45E9zFWQ2YZV0YeTGA98F0eh g+CnMxBhmTVqz2hewaUZtRIBNODQ3s3YMxl9EIfP8B78rCBeTsa5LwUaz1sU/ORdZkc2ed6a4KyK Yu7ByqiD3NkhuNOms+kLbDpLkFoN4Escc0wm1+C3LXDloSbAKFzD2OQWuqHO7VjfcVvXqp+O7li5 aMI9NVAJ/35/0zOPdc9gT66/efK9t3a/Cp7cAEShClqfnhzWrjYO5CMYb9xi3G5MGbuMHxtPGvXE GDEuNbYat2WLjhl7jKYIzkPjVwFxqlgn3QZfhYIIaZ2+QCHyNnm7nJK75GOyrks+KTMiR+WjuJPl jK7M6gFk5w3xxkCZjFAF5EKyoS4j2QBk/MMAziFWAXMojzP8++wh6Eb4h7O/tMBNLb5ILF+WFIHY mJUNHR0d8l+PHDnrlhNnP+B0eQeyKjHmv+xRxICxJ9HVjt8XEdfKAZlrWf/MNS8TZqQVgHztCAfY pnysyOORnVSkiLIUoRE9Cn59m/8OQYZg+JOEgHdDUm4jtAtqK7uYerjFADrhsyCMi6xRImYhK9/x OxBCpve6yHt6xJKM72TngoyTfzgX3K6AdBfTIXyVuON/nDLu6BBBSBg7eFKXgAyO0zd5ZEVmxxo+ owzAnUjaWLO1skA+Lh83/tn7aVT5nXI6yryGaNzoC0aNkhQPh3RuLqL0VBdHFLfpaAHdUrC9gBXA x2cr2ILDxTIfngNbjEIPhNkvNEAXRzUUPZzM5uh2MM6dDsRFIxcGP+oyEZBcG8xqRbRJs/gKtgRp UDwuyJldPC4oHof7bzQHf1xQcF1QKPIoTWeYPQhrUVeP+4wnIdiJ5+F/baiIF9CjhHKbgkUQ1D8e 9M+/k8GGCGbih92BI+EVIJ7smnuud809pbnEoivIkgh5Rvz5BZ30hvYYR8t5OQ0ECHsPv4VzgcEv ch2guls4OWHr8cUYK/JY7r7GPhHXeXoZH07bhMviCFKn1d3L+FlVCPh189UYHkhkGfYX6/LFguDJ 8mcXrnowctuhJ15sj08fuvTHHQ1zxqwZLCceGDdjVsO+nXu6C9nj184Y/MAz3Q+ythtumPDIfd3v 98rwz0AvHnqrlqNIuhz2vNqp/kX6POekdDpHB948qdWAYG5U6UPqUd8xX49PjhpcNpfHCRlOdR6r yWqz2PJ9Qm77hAw3C+ltFtIb5nlWepuFKDDncWQKo11Ib7OQ3rj/PoNQs5DeuD+NkwgQCWaxQJhp D4KYxsF1iwBKLsl9J31sqW+7L+Xr8sk+RP67PYI3T+PHAjKcd4EFLxbgGRa8IMCx1HPRLQR4xmfA X+H89wVhnFccaxH8xjNwIZQs7idCuvgv80MkwPIJHLjLItejcxhNBpMe8c1qAtZSkNpNziySeVjq Mkj4ZQLLWa+QQGwGxeufWvlR85MTVFNH8aLLWp6TEw/urFs6tvzW7ha27rrFw+5/u1tEgI+ELVII LFqJny7a4xanx3O495GvSYg2+EJr4ZBfVDj1Jr/lUt1lhqm6RsM83QKDoVId7BzsGeCrU0c7R3vq fNOV6cZJapOzyTPJt1hZbJyjLnYu9szxXU/dRp1ivUrCZoXpKsu10lxlrulai8kbkvUOiAxXflDo UkFBBnpI+oyJqBfGYdaxwANrOLuh+qTonwA4HgTAUQGgS8NPR1WW4VSLXtVHYSL2/xgygpdfzk0T wLZ8YrFBAhFx0gKHvTk7oxPIhUmS5Vohf/gPmADPGh7JxQEj/QPcRAFSzyPvBAyUJvxMy/mCC7/y we1HBBpoxsnKZOMsZZZRRtiZCFzKEQdFccZXmCoXK1kjn7nrFx9Sz81/vfvj9Im9bevXtbWvXd+G H70tvHdV+s/dh/96Ow1T69tvvf2bX7x1CB1an14gx4BBJ065ztLutah91UvU0apcG01FWSRaZInn lrvLc4fnLo1uiRoGewcHr/BeEWw0XGWZ7p0eXGhYZFmgLvYuCnZF33F95Pso8E74uOt4+Fi0J+qJ y0k16R4gD1axR6pOUz81/zU3rZodNhiT3BWn88AVR2z+/KMmqpo0UzP8/XJUoDAq0IldtM9wLhxz bRKIxH3mBAqA89GUmV98QckXWpxPtmkFzalgFc4CQv6zB67X8SakcdbxJlxP5x1vp4U0Fj66jONN RBVARIKUqT8Cxxu9eGs1I4jhePt3txu0LM6PnB17vW45vUIVW+3i2FmhA0cWz/sD1j8z+P75G44u XPnxzdM293M8u+qGl55b0bIrvUD52caJEzf1PPR0+uzdYwZ3n5WeOXzwrd+9dej33CNwWXqBdAw4 VEmIDtTuNbMkK/YNYaPZjRZdrbvWP9q/Jbw9rFTm/L/GrgVKiupMV1VX1+NWVdeje/o5j56me7qZ njCz82BsQKd4mOGxMiKPODhjyBrxDKIEJCo6QchifMSQGE8CnE2OrxyVs254DU81cpJINNlZ2V0k K1kNeyQGOTHr5hDXhEzPfv/tHoTEnLMNfftW9WO6b9373///7vd/tzPVUz8nPCcFAC11U/im1Ir6 TfUnlDe8d5X3zHNxZ7KUMYvgy3WZ86RPm8ulIelN8xfxd6LvJd5N/UmykSscSQKxCSkRRPhCKBbq QMq3c9wWHdu3V9ibbLmeBzZIuqZwgwc2MAJVvMbmgY3NAxucxURKI8eO0jxNpoL7IfzlPdx6rHf/ Eq/J0jAjXAYlj2lUPsBUjr+pibr6y6OZT8Bqxs6TW/dnFwb6StCK4bgajz8RvlyG0rQ0b1v6Uvm/ 1/z7xlfWPjXW+Pzddzyz684vPl0ekrTpC8UpovpE+e+f2frH2YF/Gh390U9OnPwJzXD349Icw1Vx hdf86a1h0ZHFSXKnPBvi6Cvl9bKiu5qu6VbY1S0hoIkGHxIC0wvfQJ5PJh0Ww1LG/euRwkVf7yPf vSRSAEGKz0OXeBS8D1fJxRzPFBZ6vRNIJDc7mExmwJEYPL8OMBbvs5Qex7ERwXmN1PWoB6+j/JeK T1CJ0JG74N7/1FVDPTfceNWsWdNvjNTLTU+unTvt2Xxvz4p1YyeoFXqAMO5BK7QFYv69ciaSmabP 1+dkl2VuzgzrW/Ut2WfC/9jyw4Clx5LxWNuClpOxYAo8cclpF1l8QBvQB9iAMWAOWKu0VfoqtspY Za6yRppG8na+KZvPTp6aXc76jc83fb6wftJ6kMkeY98xv1nY1vKttu+xnebT+e9hR7JXmqJYEqt4 opmJCihNlTPZiQp/DZkQ/hqq8NdQhb+GKnWkk+XVl5Zr+ZzJ5GS6qUY2ptQlCVTOJFqo8RsSPYm+ xGcTuxKvJxQ70ZBYk/hlQm5IfD0hJV7CtalBv+DYmY+4RAJkBlq1A317LIQ6UNvCVLMvEu2kR98J uZ2iOGWgbnWdVFdbo8IroiUtHugQDR6RC5nIME1icu0UowE8pWzCD8c72+ntrRz/4f4tzcDAgjBa UKbpnYk0vSvB16ISHD9LYDlsr5ptxlv315aON4uovYtRKS1FpcLl4xVqB1TOHaBh2pzkf6oRaN6K 9qPtUk/7pnapnXDArMD/ZlV2K11pZWkpr9AXoEpF/ymdtbkBtvnXs9PcelAQg68IC8GZ91XYIvNL QSS3WgI/qgr2YZBXPWASV3JAlVq3sLqUViyuvSQDkZ4BiIEX9by/Fug696A5hQoBDmnT4H91OQ0p QX7+U/WTACQ1uY7nhJ2AkrHSKUEvqCkx+CkU9REcNoYmpYQMhHa0ySwlFvI6U4pySmhw6sjPmhCO hIQkp+w3FzdvRlg9caOsZLDJL+re5Jvy2BmgE2txPOC+CO4TwlKRkCREpWev/dC9w3d35R47tqNv 5hXNjy7+0kvL3d3mHUPDq6LR1tSWl7ctGzr2pdffFK+svXXdzXOunBTPtc/bvLB3Q6GhOPfeW+LX DVzXPam2LsyyHTOHB5Y//pnnaZxmx38nNQd3QGsB+UIMfXBSEy39A5FFZRPki7BQxcSAEHWgZsAw dQcM28mA2mp5OVMcV7Wr9atXqF9AXu43VFmA5/SEuls9qh6HciBN1hS4oUKTNa/8ji+y4gzFY/zM R7yn4QxBIBWfjOZ+1Di3GU9UvEr1iLQKvJepe1ZeCndgDuZyfFjcP0MWHjg80rww9YJy5LxGYWux mItR+zV1EdLodnP9Gs52kpzk3874u9UtW7bs278/XCzUP/m4c9XNT0k3PSKqq8tfe2TssWtaIBOE +B627DTtjCL2HRaSaBsdkbuUDkeJWPuB3+FFOothMauFo6YYjhrAaV00k9ARzcVjFE4keawS41FK zCOjDRwPYSe1QIxHKRwG5PFJLEKtgOMquhTjASeOPyQiobJ0PCYejYmxhZBtOOrXUGiS/CApfSH5 RHJ3cjwpJwFx0TMcYiKFubR+XD+tg2XHlxU5jlWdOKroFiKUCnpVAZd0HpvoHFzSFyYugwQwXbz/ l0EIZhBqd2Ro8ZmDA0tJ2QlZtkVMIUq8RCAimynB0twUsuWA/jZvhmOE8VBdJcnj4gA5jHHEfSrV Az3Db9z4dJ9jjBju7YsWbZ0+8p2Rubf1dd0hfXNs39f+pnfR4q8/KJUAv4gCLlHgLK4OE89V1x9j QU1gmiIqF2loWep+wdbipWw0cs9SB7uCopBxS4zsu+WWdISZnRoVIG+d24dHGGT+iFf8h6/XN3YK BRQ4OuvrQHKEKAocnfI3FqYgJw6FbU4WCnoTKwldbK7Qy5Yhq75fu15fKa6UhrQh/W7IU98lbdDu 1u9iD4gPSF8JPKQ+qD2sf1fYrj/KnheeYi8JB9U97DXhFXZKeIP9RniHXRDOsxb8HBYXoqwgNLFu 1if4SMv3vWhnEF2ps0qdhSafQD9dwHc679tkqhkJKSIaASWPznF3lsh5/KwUDJoGDGDrW0Uw9XAf LY4WhdaLZL1uBrJXTmcRXWdYcpDgmBCLK8gYXBZOyVJUEHgEMdiKTP2M5vs+kD0Jkp+p/T6gLGTe iSkowkq+mDHO/RuNXaT4jA2ODSbj758hZi4Ga+kiI8stXZ7W0w8HpMpvmDCfyOHgnDlOkQI3Svx+ efUPzuTAWfnN4fLtctPYllvWLLlTerCCzRHn6SB6hyfXTeSmeeSZcutTIZXwEs11gouzYWYF45Rk 2tw0lXgCzBCYMTyBqZVqrs+PmRsQIRCmorVttIZlwmCBvQ9pLOzU4gLJ4ehUxdC5mHVGR52To84J nqZW5dXxX0c/jAZDCiMwIjbLk5k0373B3QqVLUyJPHWMhMD4pF+pAM/6wNcbGjudWmQBYGx/4B9s yHbKiqmHlZSe8ILYUksxkFOneY4QDkTUWi1l1CGCzanNWjEE0W11mjY9NCfQq/jqNdoCY7bd6873 brCv826F+tIt3gblHnW9dlg5Yh/wfq9c0AuGWxAKVj5UsPNea+QKodu7S/uKtj2wzXxWfE56zsDC u3BAORJ6VT6pvKmflc/av/bOK3/Uaw3O+Td56fAyxEubl16126ZYyJY9wdVULafauRCFcSE1YIlm DquGJ/1uslIWel8zVbB3USSsMMNtYkV3iXwdG3BXu8Puwy5zmYy+SJejcmHIraW+PEFhbEViXYU4 7Zyhf5XZH2XKx0IBURvVIBhpGmIU5iAL4tD4AjAaPfgs8/yVzA6lf+SqyJ11Pa+IFYVgUA3hOues UASZcRrAnSLTQHzTiO9YHSmQh1M9WbNdM2Txr+fBjlOmNzHhPGRNhAQW+dCxREqF3WQFrEPisz5L 9zFxDbuPeHDSUl+HwuIa9z5In9CR4QTFFRwnRgqd+Ox+8cPwh5gUQfpNXHN+cDA+NrgW/2mQDcY/ metYHXXw9TH2/h9URxVMR7oT2ZHuC3Y3LL5+xEqbaelFyLyIuIfGj48IbXYadPbTnB/Haa8Ldncu RsadNn58j0pSWNilrxGMug5OgtTGT+9R05WzHs6S/MZh+qADcAXx2bBWx/eqbfSJe4UrJBKUwV+6 +OH80+h9Mf4+d/z0PpaW06QNyXmU1VSNEwe8ktCCOwb4nvDH3DyObvN0MJ7VR5xLzrUMxzjhMpAP iAvKLxzZ2SN37Dz8eNeVB3aVR17YOfnnMDD/cMb9qXT72PafjUorL5yShvf/6XXMQzbmof+BpXHE /6zOQzW2aCiypGPx00KPtLlHbrcirZP6JCk2pA7anmiDOYgcmbf9axOl5fa35W9rkIywjwaPKkfV n9m67UdLyUBYr7GSTpc4zdgsbjW0Vu8zcr/ab1wf2iZuZ9uNg9Ih81Xjp6F/dk4F3tD/1fqF8yvm TQwuw8SOoHbcgmOBv3MWy2Wo2QpWkAQILSu0LkSp8WgbHvql/JUKZA81XRfB6SR6J/wxzOeWaNuW Y8CpkCwjYDpMge4Tc44Jx3TJyQk6NH/B5LSOYXE/ZwYApwdA1YagmALEBdKIrM8TvXnWRjPD7M8p +kYfFM/UQV+5VtnExWFm+6F0YKOU6UNbznOHeaA6eL4yWWCucH4FZVCehVzJ56GS5orBKjGXhIhJ JK9k2w9ovJdWyh9rP6auO0ObgbmEMj5HQvG6EgDft32jDgqHMeggxvjx3sYSEqbAwa8piZnGko60 nok5p5+DpmifwX5MOB3wy6d2d6M2KZAXbXFLecd/PT2ltiW37+flR8WvvnVqWvk9qSCW/9DbNqvj Qtkc+xdxfn+ZdmFoxIr1b9FHkuL/VvtIHYvY2PyrNmF7iqGEfQ/rt76ZrvaVRGsx+VYyPoplEXrg QTpsGTrOPhu7vtKPuK22VIgss3cxiPT6uCDpQlunQwWEeryoFffyRt7MW1PNqVZXaIdrYG+D8Nxo v9cf7q8Z8obCQzUblDutDe49kXtq7rcedh/xHgk/FNnOnjNedF5wj0TOsV9Hfm+NOX+IjNfWT/So aNioTcn2HHsLFpwTF79+BUSoJNsQXbwb7HAQuj14DolIOJzzWAQHEEp1zZzBEAYzUMdN0IHp9wu1 Tq3UWvtyrYSdY3v222gLP3JIWuIbPZ7vSZ/1XkbG8SFx1gFbzAhXp2AYl1RaC8ISbWafGbjWHDcl iAXN2tcKDhc+YySVHoZhROONkUoQOhGJBMWd82cSENle+34SxH5eQ4IxAoeJHsUpwEFQvklwlroU TB76D6xeCNYmDmvzAvKLzwrG+FkyXtVudViIjL+N7GGWQQYxRtn+GiSIVZLB0HvgtEBFCN0nnCfU j/MzqyxvuDDwIRCi3BeZ3jJjLjYTCBrl2374VjHTUHxnpLx6ZrZteFln+ZadTiGbutWukwtjO764 efhO6dYLr+6a1b+YIpQXoXXeD3ZJQGhHnq240YcwWfBJSZpQ9BaIFP+kTCJTpNhHdEHkw/xW6CGV cWCT7ovfLS9Sv/zRRgTY/DaeJ32BT7jNwjla24WHDd0SE1bv0h1DPt4lpLJHyMc7glT2/2it7v3R cdmuHzOwM+TVwqeFXmEu9kacLyzATox9oOktwq6Ri4Ul2BFxGfZMu17ox26SN2CXMYg44wZlXdzp piBLV5i5ZMHCebOLM9cNfW71NUv+DxNyVbkKZW5kc3RyZWFtCmVuZG9iagoxMDQgMCBvYmoKMjMy NTcKZW5kb2JqCjEwNSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA5MDUg L0NhcEhlaWdodCA3MjggL0Rlc2NlbnQgLTIxMiAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstNjY1IC0z MjUgMjAwMCAxMDA2XSAvRm9udE5hbWUgL0FUS05JQytBcmlhbE1UIC9JdGFsaWNBbmdsZSAwIC9T dGVtVgowIC9BdmdXaWR0aCA0NDEgL0xlYWRpbmcgMzMgL01heFdpZHRoIDIwMDAgL1hIZWlnaHQg NTMwIC9Gb250RmlsZTIgMTAzIDAgUgo+PgplbmRvYmoKMTA2IDAgb2JqClsgMjc4IDAgMCAwIDU1 NiA4ODkgMCAxOTEgMzMzIDMzMyAwIDAgMjc4IDMzMyAyNzggMjc4IDU1NiA1NTYgNTU2IDU1NiA1 NTYKNTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMCAwIDAgMCAwIDAgNjY3IDY2NyA3MjIgNzIyIDY2 NyAwIDc3OCA3MjIgMjc4IDAgMAo1NTYgODMzIDcyMiA3NzggNjY3IDAgNzIyIDY2NyA2MTEgNzIy IDY2NyA5NDQgMCA2NjcgMCAwIDAgMCAwIDAgMCA1NTYgNTU2CjUwMCA1NTYgNTU2IDI3OCA1NTYg NTU2IDIyMiAwIDAgMjIyIDgzMyA1NTYgNTU2IDU1NiA1NTYgMzMzIDUwMCAyNzggNTU2IDUwMAo3 MjIgNTAwIDUwMCAwIDAgMjYwIF0KZW5kb2JqCjE3IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0 eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0FUS05JQytBcmlhbE1UIC9Gb250RGVzY3JpcHRvcgox MDUgMCBSIC9XaWR0aHMgMTA2IDAgUiAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAxMjQgL0VuY29k aW5nIC9NYWNSb21hbkVuY29kaW5nCj4+CmVuZG9iagoxMDcgMCBvYmoKPDwgL0xlbmd0aCAxMDgg MCBSIC9MZW5ndGgxIDExOTAwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ab1aCXxU 1bk/y519uzOZyTaEzGQIAQYIJEQIjjAhGQxENGw6IwYSSCCg7ERlC1GJxAFtpWh4Lq12r6/KZYJ2 aNWk1vDkPX2lti59bQVX1JrW+qpYCzPvf+6dREipP9+vfe/MfOd/zvnO8p3vfN+5y7lbNrW1EBvp IJzUX9u0YSVRw4QthFDjirVNG7R80Rjgsytu3OLT8nYjIfonVm5YtVbLu/sIsZWvumFrpn0AfLOx taWpWeOTs8BLWlGg5ekU4KjWtVtu1vL+PwOn3LB+RYZf9AHyI9Y23ZwZn/wWed+6prUtWv0JVwDH bFi/GXKKMEFGFNqwqSVTn0YJsR4iFKU2chNxkKuIATmZTCLbCdGdspVjvlTl66neEbv+0DJH6GPq hdgIR3b97EmBfbqn3jxz42dem980D1mTWl8w0K/hyVQ9Oh955sYz1Tb/EEdwRbAlycZgkqwCNYAW BqvshLDZRAYxsovVEMpmshDaBdkMFkrQ4B9/wi5D4WXIuAvJU+DJIEb30K5EfmE4Se/okbMrSZWd dhEZxOhttBN9BenuDN5OOxMs2PETugvdnqQ7wivpyVPZOSN+9RKi7TuyvY7thdtLt/PtO/J+8SKK brwJ0doNiG5Yj+j6ddneZet2Xc+uX7drU/6WNrdnxKo1iFauRtTS6vZ+peWhlhMtvKW1c2N+3ubs bdV5/q0gdpQv4HMxsvwUn03qQYyEeWXCYq88mu7j0xL2TKLHZK2sr7LwCYTySXwyViDI/sz+mxiB byaeZsEk+23P082YK/tNz+TplQITgRLRCxJut5r4daK8MpMYNzGT8AcyiZy8TMLuVBMnEk4kWAe7 WYhXFWRbSD2IQbUNSDUgZWFXEC/oehBHrg65OsLYdCaRbFLIpgFdwDI2WSibTcpgKXAkyieyyYmR hb4kwJVdeZSeoW8meNBc5aN/JpT+kf5BtKIDGfwgg7/P4Lv0tFADfQcoAd8Gon763+mbPRaIXlWA AkpuRHy7YNEDdL/a4dcyuJ9+lejR8G6gAfgVoBjwLvpVTLm3F1lKNiDuEAx6TWK/FEzShYm7BVyV 6BZwSc8uHoSBVSZcuZVVJjqKFqtCydSpohS+9CzU92n9pyz8Tn5+5X338+AD90vB+7vNwa+hv7v3 64P70dM9oIPdLHhvNw8+1E2/0X2ou7ebP8lr+RwxOT4n0cmCwiSqe2RnZeHTHE5ATomYV/Ap0Jqv ysXLySRQGFQPkng5dwsheFkGS7kbNUt7kYUXwnp8IMY+TDylh/28keg1iiHY64mcMaoJvJ6ALSTZ qcQeM/gne3olTJW90hMoFvb1SsKDRUP9FxMQqcrGjrF+oU/2DOtT8acZ3Cdkf5LdyG4SU2E3ZabC NmpTYZvEVNQ4zBoHO21MmC1q78sSOblqYmli1Fg1ca3arsrNlqgNRexgcxFnszlkNIgRE5tA8kAM 4gUTTo/abmyPzVkJawsIa3uKFTGfWG7mZ76EFDyO/nzYQ0YiFs5VqHHpJ/Tn6kKeoo8TH/HTk/Tx xGi/L0lPJkb6K6vy6e/ob1Wr+U0G/yuDv87gq/QVtYNX6MtqvZfpr2BdSi+ylL5Ef6UW/lItXF1l oS9iHkdFTF/M8H6h8jDiiQQ2gaOw758L+w720m+Rb4OOgHj6FP1uIsuDZaB30n3qgHszGAcKs746 cTu2Cbo40cEBixK36wALEnsEzE90CahPdAnelYlOAVeIhUrSaYk9AiYnekVhkVZoD1vA/OyvUvCv olK6L2z+WBjmJ/TUJ1RkTYc9IyrDb8PkRW7iIZujEpKGj9QfaTyy4UjHkb4jJ46cOvLhEdORQ82F 756WgnfEDcH4Xn1wHwhNfnTXpLLKu+7EkGjuvnNkoPLOvSy4t9MYvPUWKXiLmEO6r6dj7jzRf0/H zGoNp1RqOGaiOq61oyBQ2dHOgrva1V7D1p2ROZU7kWlHT6JrXxe67sIM96Dg9k598Lbd5uBu4IbO jk7W20mrzHwhX0TsvJ7PR3wlv0rECd5cWLWYX8HnEQf38hG8gFi5g8vcCbRyG7cDS4BjiY37wQ8A R4LvA5aQEPeDRoK8IAfISkLsUfYYO0Ss7GH2TfYt4NfZN9hDwKPAnxAb6wH/caACfgJ4FG16QIpo C3oY9HXQLexWYmftbBfiHWyniFV529g2th2+IjMnc6FfG7MzB5Ayxjix0hRNM1z7sZM7yf0gJupi r5fJN0C9oJMgHXZuG5kJ2gXipJCm4Dd5aOuFTFno0wPMgxxZIBlkA+lBlIRQN0Sfok/TXox3mCZo D/AxeogqwOPA/yA2+jPw+4F94D8DPI42PwP1ibagw6DHQGvpOroe7ZrocroCuJQuo41qfmUip7Cw ahZdSWaCdoE43QrudvS2Ga3agBvQahNwK3raDNogegStBDWBloLG0wnEQUfTEsRj6Fhip+NoEHEu zUOJi2YhdlMPSrJpDmId1SNmlCOGC4s4/H2YSirt8E715F7i8VR4XFM8jnKPtcxjmuzRT/LwUg+Z 6BldYh9T4hgXtI8POooC9lEBx8hCu6/Q4ZCdVpPZYtUbjFYu6azQtJXwcFZ+gPCsQj0fUVjomOnY 5eA+Tgv5VbyXp7nkpQW2XEO+zSPn2FyS2/ZVLx0fGhcaExodGhUqCvlCI0PeUG7IE3KFHCFTSB/i IRKqL6eKq47ULZqlZFHgwllKebAuyX0LlLJgnWKqXxI9TOldMZQqrCtJySJF6koygKv62iXRJM0T 7E7vUTFvpa6x887YYUZmKbRLCSyMCgjPjyq+rqRMFkUPMzorFospU+vqkSazYsECpbkO1ToKYkqZ SHy1IEbqlOnzFW9gVnB42CwKNm9R4XPe4TGjI8q4SJMyPtJY83lxMEiQgcARJRVpSlIWuIA5WHFY Z4PFwM0ImWyS7Ygk2TZ0w9ov3s1QuyS/MpLkV6AqrxdVt2ymQ7yLJDZvQSFV4+FcdfAtbRDkAg4K EDZDDaKp0IcK50Wq2Js1BjmfTYZ6GiwdxPMGOW/amT5Fq81BWh31xoJBJVcJwEgGG2R6FECTdIcv sqYmSXdq0K7BLg06NLhFg1s1uE2D3Rp0anC7Bns06NLgDgGZmeGu5FK1lIU0uEyDGRrM1CCsQZUG szSo1qBGg4gGszW4XAD0hrltPmwS1l+/YFadYlwAql+i5AeQeQ6ZS5CxBmYRfZDk4cnoOVI8GGsP MloszSC5IpX+jRq/O5hOtaXVNCGpV0XZPxLEs5cg6R/pRLTtJ9hQ05em707/mfSSVuJOV6UPpsUT 5d+GW9Pt5CR5kRwnR8ij5H7yGtL95GlylPwreRPpY0g9Su4hy9H02+RB0gl8hDxMDpBNKBcoSvr/ tmM65oKyM+QM6aZVZC5weDiAXg4ML/y7+XfS+RfhvZYuIjvIDtbG3iJt+N2HHn9IHjqv5mqkv0M2 4/m3nw6Q5fRJshLz6SLN5CusPv2+7jjJ5jfjkWe99JCwhAvCvSRKtpJm/kD6T7ATh6EeF9VD6T+J Z+kLwhfVW4+xB8NRso+aSTv0NhlP5veRWYOMCxE6PIM5rMBcbsWvG6vRg98OjHv3+TX1NSI3KLeR aNY6aEc68a4BIX0adLOa7Bf6zljs6+RGjBAiE/A450gXwm5q0y3prekH00/BGsTqfzdjFb3I/YDc TbshwXJyHbmaPY8HO5Fbj/zVZC4toDbydfRdoY4yFGW8imsFwsZFGJRPymgx41uQUgvpSwdTdD8u zGfIc+RnJKnK8wDZT+KkA3rYAvu+ltRD9ul4LaHVe1u1YSH553WWkkWwPQTY4AzM57XBvgXqXlJ9 P/Pu5m/kE77fz5/R2ggtaiE1mCDkBayk5g1d0EYb9LECK3tG9R6xfv1YtYdha4O8q4e4x9S1FfVn kDIhRXp6uh26/09yDVnPenDDchvadX0+1FDqhygdtORc8hqdMcS5MPGP2P0O+FA/ufeCDjtJA2m5 oGRYZrj+hrEvktUN4NbxAFbtCYy3Hb8dF6l0FPbdDz1tI/NJFdmDdXwN/tEKH26Gxl+kPqzPL7CL XSw0od8TWJX1fCXPrPLFqsFCxO8iQTegFRoJlWD5Q7Y7WFWz3cHcBThDx8mr1AX7+Bp5FTbxKPkR 9pJVohRWrIX/3RrdStaRcZkfCYcXzKkNXTq9ctrUSyqmlJdNnlQ6ccL44LixY0pGF48KFPl9hSML Rnjz83Jzsj3uLJdTdthtVovZZDTodRLH/fx4mqvkVkcja5S86kZcC2sCsk+xXvnhvFKFuLz+gNNX XhqbkKml6IIKyapT3LjnI+FpMUUfHF7lSoUXyx/50Xie1xdRpGL8A3ObmpUxC6L+gPyyd4gfQ7dK fnXU7/cqrBj/OWDhP7fJ16zI9SgHQy2Zo5D6qKBk+o1pKCTT/DHEC6LKyMEsbkUvIuRReFTfMDGv pHH5sDWvukYh7sPE+oZCPKLah9MIHsKUMbg1LpaRUnsjpQp1f6TQLIV65mFKFw4hmp2adhEdRJrX BCLNq6HR5sbPdfqhplG/L+6LL4g6y71+vyo07kTmRw9bzNWB6hYzZoGbZhSQw2YLSiyiAMuy4TC1 zqBqglkj03HHbbRBfS4hbkTQGiW8txGJQA30Bk7W5xw8JO87n0XQTKtEUE1NUXVMRV+tGDQhfKuV cJNC9voOj++L78Md//LGoLU50Nx0XVThTRDqMOHFkdZFyoi6+mtRBCFAja0+sdw1aiQWzxdp9cWR F3UbEQdq0PTC8ubWlkZhJrQxUAOeqTq6x9/nxSNJdE9EcQYVG5rbtr3l5fFI7mqfyMbje3zKQ3gU OY/rF3VgBLkTxvvikQBGQ2eRNbPEipUOLZtqjXOa1cUJ723yKR3L10Bn+DftG7R/f1xWrJ/4sTpY H7QU3iEULKi5cY2Yyhq0lAC++N4Wdar71KnBXsVtpyDRENZPFqP1tdFIayACfWYGhELQnhcPb+v3 K3lB0TAejwgRm5ohvdAM/nm4WYcYWgY+4Q1SyFOthBepQBapa4ARw001sUxRpgI4EtZBCTfWxGJi UtoCKIbiPbqJAV9cdGooVtxB2f8seH0TxtctiEZqhHWiJquOXjaQ6x1AGg96g8U0F3XipQNCSYKz MFA3X7OCVqEfETUu0hwYWsusPKpm6qu9vpDrfQFtZwdmN8bjswO+2fHGeFMy3bE84JMD8cNWa3xD pNGnej5F+Y/3epXZ+2KK3NhKp2ORhb3Nxh181vwlYnlm+1qbUIL/zIB/mtfvRNdaHewcF2dn/AwW D7sXfhaXP8CMrdiRvL7ZYntJYlfwKvI04aaQZHEUfrACQ0Sa1Qj+gcdc5hWewmPFkdULMwry+jGk ajBi35ufKUUnfr/wob3JMFmOjNIxP6rlfWS5N0HCpUGsXaPg9A1yPIsFp2OQM9S8MYC1yhWP2apN /D2bxn4+ZM9xZ8DlqxSbOaTDf06z0rcIc/x0mmKExtTlzqqOci8TVZBiXi5S5iAuCSElJ6g2FDrB LhmXA74TAUUOKrrqaJ83FPPJTmyQdMgYMj0KM5VPBI5TsYkSt6zQkEKzhVsRbKpQIzb9nGlgDjX0 ReKNGes7f36oKmo3tw75kTYLOK6YJNQgB+C3Xk0fTldATPV5Ye3aBU7RFc8WToW1UTU2N6bYxcVO sX+gRpictzrqwzYEt52vJnwRX6tYdcXXWKPuBzGv4A8WJ9OnGmvE/heFoaGKN2PfsHKoLeMTGTXU LYoOphZEd3q3xSbgVGx8XZKYcCUV72SSNN2ZJDUFR3HOxpctBXvReJ8vsroGAyKzeDwKxvmRuno8 bFOYfjQQE1eSOc1xnzD+ZkxLRTBa4rFS2OvCKPZLvKrxK+GYdyjZEotNRz/XiH7QBNXjMfSwJtMD UC0qPYdK0fF12KlG10ex2XbUwNBrhAtjun3wqj4xYzGR2JCkkHjn6tyMzNdC5tg48JdovcBWO9BF LB4XfS6MBmDm8bg3jnlk8njDM7wgnClIEtEEE48kaUc92gIC6v1BJOAPCM3HajDUddD74C6Fs8cv 1vDSIbnRchmkXapquPGfpOGmL6Ph5V9KwyuGJL1Aw82QeYXQcMvFNayw0V+g4/NVGtZUGr6ISlde oNJVX6zS1iFBIdVqiNeqqnTNP0ml138Zld7wpVS6dkjSC1S6DjKvFSpdf3GV/l8Y7YYLNLzxizW8 aUhuCLkZ0m5SNbzln6Thti+j4Ru/lIZvGpL0Ag3fDJlvEhre+v+n4W3naRgHm5QwPFPrUqRX5yC9 0vVklYSndvYnHJTUk37pfbJeZ8Iz/2zSz1IkIp3Bmw+CRlR9XLOigyeQ8uGdh1aiFv9DEc5s/m7I vDf5O/zB1yg6SPV5MKhJI64l+BAFZMGRkAg+/L5JR9KXcZT7JHuZt/LPpLB0UCfhcBxsHX44DjIQ 94/0TCKCSl/41QtqNHmS3+l3FiOieP49G+YdZzt05K8kLHWgJQ6aetH+XrzrMeMt2qHwgsosekfW e1ks5KJW1xUudjsOVeyz7MxkMNHTpjMmVmuKmlpNSZNkMdE5xqPGvxj5KCOdYqSz9Av0rFhHdTqP LqLr10mS5JaYWcL1NjzW7qw1O+Y61jhwMOdwrncypz57P+WW/UTeabC0k3CuYT3LwfcMeImdnyvP G5AHSOnAzIHJk+iypQ34k+DShoaN6h8R0shsLHf6y6ScbKdM/MV+39RLnHLJRBqkvfSD31LHigdT 21JfT71JbdR38y275r38yqO655a3/Th1IvWV1JoH7/8OTo509yyp1nQgfQYdWEkWeSy8pcRAK/GB jX60nr2jpxOdM5xXOrlzms1ZOxpHUo5LHEzPP+HMFHHQbIl+z0DvM9ClrnWudhc35Xryag1majbR BaZ2o8FtNBps+w3UYjGSLEyYyO06g85os2LKDiN1cY9xA3Nr88Ys1amXOSsrSzH9mQMi4aqEEvbo 5GBQfpY2BDHxhgYidBGEAjQVZHtkHfXTQB4t9zmn+AO9tO+lN1Mv0T+kUqklz9bQfakju3XPPdmT enXHuTq26dxd3EGnvo15r0qfliqlq0kBKSGfhYvH2iptc2zv2SSTnpr94/zsMz99l9P3LPTXlvcs f7HwVwzUgBvP8Fj/qNqthjsM7PdF9Pqi7UV7i7hOTx8pom1FnUXs9CiaU3y6mD1LKQ6kT4Xn+AK1 VjqCXkf5WUq3cnqc/5qzPGmsxFiWK6soi5sKDx4yUZOJMKej22GnFm63djvlvJzuEdmj72XZJN80 sjPfYxfHxrLFUWsPdOrCYz2tbIxu5ZDFPAsFDUB3ZObAzHPHZp57GfoccLqgwgZhRhmTCW7cuLGB qOajKrAB+WJ9oGh0xZRR/vKKKYEiQ8Ul5WXZHqe7vGxqDjjcWVKk97izy8vYx4e/vQcfPdGc0mce ePzfHnvi0VZbnr16frx61jefa67dHv/WD25J9N72VOO35n/70ZT7B9JaH7XTPLa9+XLxJp6R9enT /B3pGuKEr70fvmaqTKnsLawdJU2R2LPSWxLT4ZuSCF/Mpe/wjzmL8dWcTdfTf9e/r2eL9R/rWcRA I4bFhhYDz8oOZLNfZv93NpueTV32InuZPWF/xv6GXQ8tnQib80fW6kydJmayiSWoyS+stbrpePd1 7g/cZ90S32KmpWYaluqlRok7JGrXubptNubpNsqkG4vAsl22rE6nxQZF51pWs5zzFC0fg2ESKBj+ 6YSlaj4KlS6DUcI0hY0K29T+sFOhX1IxhZSXuZwGv8tfNpX6ZSj29WN3fpj6BbWc6H+FnlsYpPXb e8410pNvvBkI0ZmpMzSUejeVuiy1cxa+1igVOzm+XeMT8N7cTS4PT5hkoG7jKOMUI7d0W+3dJryt 4916B3vIqliZdZKbul160inV8xOc8dKGF85VVv6u4ViD8KvKSiH95EkNG6kz4AxUlFfI/rIcz+hA kb6A+j1UOXbffXT5ivbO+qbLqYM/cvZq/siBW+lu/wNjG9q7xakHxVtNQuM4V+DEG7ZhF+ad2FN1 pHPSpMwOhoEmTyp3ljv7+/XBv7yUWX9pO/zNgn3mRPhgvn2cneVmjcliBivFppOjK9GxXLw91qIx li4LM8oHZWa1mQvMTEQTzJwZXUYmoiIjZ5JLKpK4bTGjNlbAmN1soWYDtmCch1OrjfIsyp3Uin2K y2afmclGn5EVSqUSwzNfjl7u1svWbpJt321y7eZhj2k1c/PPPQp7MHzpvPUVPqQGsQGJPWhwJ0Zy o66IYCMuLxNxic8p+0Fs3Xup92nOH/9Ic1LvfkQrU/+Rej6PVlBO9XRy6ueps6lPUicO0O/Sh1MN KbyhhY/0p9qk+6AjO8khvwwfzDLRqI2OclAJ3wHIUZmdkWky57kc1sVpXjZdnf1eNptmrbWyJ8x0 nHm6ea6ZF+sr9BE9d7kSLlbipgVuWmKm3ebvmdlfrPSo87iTxU0/NrFiUwUiQ4UhYuA2R4FjgoNb rLYRNmbl1JHDPffoZJvD2W3JJt6s3UYHt2OB84yrWS5pYXmdMwcvVGVlQk0zB8rKVMKms7QBHqHp aSMRTiCCAKhrY0OWs9yDDcblkVmgqCSPZmPPhjMY+vu3fvTs6+kTP+04GKcjzn7nwVSb7vjzb6Xe +DT1UerxA+c+Y3d14buN9h7N9ngBdGQjS8KFl1voHGvMyn5gPWplBomarNxsuMdIzLKZlXKz2DNz CgO1ZsyHOgi3YRoOwxpmxzSG5gBbnXkuCNlfHnCWl0+eJNYWV1dVUtUvDLDitpMj/eUlP2mXZjz/ li7pfO0cjqgoiaRPs8d02fDJG8LWg+xVxgyMnmFU3Yam4mroxYZ5KV1CJZtZ6jYZHFndLhk253At czGHdZmVmbjVZTZgp5HC2a7VzCMNCvbCPHiqfAxiNWjbzQvIw2uDqrWNrlA9d6rH7/Grm7VHzyz3 fr+rq5+OSL2VLJm2JO+H/8LaD/RnvXrg3HdfsnXlqX57FNe8yThrc5IHwvLjNrpNF9fdp+NvmD8y MyjrRHhpfkHtNnvczm5ie1g342Y2Dt9VzmWPMN02Rn8j/V5iks9kq62wtdk6bffgamnLs7HvUdxn FNCd+AhMMnGHAVcx6z08G9+hODplY6chnCW3MpdhcGriBqesTOxFsBsoHHOEdWDnhIVgerTBX6Fe lLB9iCvPVCC/4cFTd32///KFRx7qf/7tnoPcem7KtlUDrO+vzwi/UUN6Gs5VLhZsKOS4yleQGlJL 5uD8cgFZSBbjvCoKDsXHouJGEp9HY2ciC65ZvPCqq4NXtK1Y3dx0+aamdc3q0ZFWQ9QKgWpBom0r SJxP4s6cHAR9H5QEPQd6FfQu6NN0JiBNhtKU+Ibla4blFwzLNw3Lq2Kd1596SnRe/oZh9dcPy6vf XZ9Xf9Mw/pZh+TaR/x9+N3JiCmVuZHN0cmVhbQplbmRvYmoKMTA4IDAgb2JqCjcwMzYKZW5kb2Jq CjEwOSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA5NjcgL0NhcEhlaWdo dCA3MjMgL0Rlc2NlbnQgLTIxMSAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstMTA2NyAtNzM3IDE2NDEg MTE2Ml0gL0ZvbnROYW1lIC9SV1VTT1YrTHVjaWRhR3JhbmRlIC9JdGFsaWNBbmdsZQowIC9TdGVt ViAxMDMgL0F2Z1dpZHRoIC00OTAgL01heFdpZHRoIDE2NDAgL1N0ZW1IIDc3IC9YSGVpZ2h0IDUz MCAvRm9udEZpbGUyCjEwNyAwIFIgPj4KZW5kb2JqCjExMCAwIG9iagpbIDMxNiAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw CjAgNzQ5IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjMyIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCA1NTIgMCAwIDAKNTU3IDM2OCAwIDAgMCAwIDAgMjg5IDAgMCA2MTQgNjI5IDAgNDA5 IDAgMzc0IDYyMSBdCmVuZG9iagoyNyAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1 ZVR5cGUgL0Jhc2VGb250IC9SV1VTT1YrTHVjaWRhR3JhbmRlIC9Gb250RGVzY3JpcHRvcgoxMDkg MCBSIC9XaWR0aHMgMTEwIDAgUiAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAxMTcgL0VuY29kaW5n IC9NYWNSb21hbkVuY29kaW5nCj4+CmVuZG9iagoxMTEgMCBvYmoKKFN1cnZleU1vbmtleSAtIFN1 cnZleSBSZXN1bHRzKQplbmRvYmoKMTEyIDAgb2JqCihNYWMgT1MgWCAxMC42LjcgUXVhcnR6IFBE RkNvbnRleHQpCmVuZG9iagoxMTMgMCBvYmoKKEZyZWQgQmFrZXIpCmVuZG9iagoxMTQgMCBvYmoK KFNhZmFyaSkKZW5kb2JqCjExNSAwIG9iagooRDoyMDExMDYxNTE2MzYxNFowMCcwMCcpCmVuZG9i agoxMTYgMCBvYmoKKCkKZW5kb2JqCjExNyAwIG9iagpbIF0KZW5kb2JqCjEgMCBvYmoKPDwgL1Rp dGxlIDExMSAwIFIgL0F1dGhvciAxMTMgMCBSIC9Qcm9kdWNlciAxMTIgMCBSIC9DcmVhdG9yIDEx NCAwIFIgL0NyZWF0aW9uRGF0ZQoxMTUgMCBSIC9Nb2REYXRlIDExNSAwIFIgL0tleXdvcmRzIDEx NiAwIFIgL0FBUEw6S2V5d29yZHMgMTE3IDAgUiA+PgplbmRvYmoKeHJlZgowIDExOAowMDAwMDAw MDAwIDY1NTM1IGYgCjAwMDAwNzc4NDggMDAwMDAgbiAKMDAwMDAwNTg1NyAwMDAwMCBuIAowMDAw MDE2OTg1IDAwMDAwIG4gCjAwMDAwMDAwMjIgMDAwMDAgbiAKMDAwMDAwNTgzNyAwMDAwMCBuIAow MDAwMDA1OTc1IDAwMDAwIG4gCjAwMDAwMTMyMDUgMDAwMDAgbiAKMDAwMDAwNjIwMSAwMDAwMCBu IAowMDAwMDIyNTI4IDAwMDAwIG4gCjAwMDAwNDU0ODQgMDAwMDAgbiAKMDAwMDAyMjI5OCAwMDAw MCBuIAowMDAwMDIyMDUzIDAwMDAwIG4gCjAwMDAwMjE4MjIgMDAwMDAgbiAKMDAwMDAyMTU1MyAw MDAwMCBuIAowMDAwMDIxMTU0IDAwMDAwIG4gCjAwMDAwMjA3NDcgMDAwMDAgbiAKMDAwMDA2OTYy NSAwMDAwMCBuIAowMDAwMDA3NzEyIDAwMDAwIG4gCjAwMDAwMDgxOTggMDAwMDAgbiAKMDAwMDAw NjI5NiAwMDAwMCBuIAowMDAwMDA2NTc0IDAwMDAwIG4gCjAwMDAwMDY1OTMgMDAwMDAgbiAKMDAw MDAwNjY4NCAwMDAwMCBuIAowMDAwMDA3MzY1IDAwMDAwIG4gCjAwMDAwMDgyMTggMDAwMDAgbiAK MDAwMDAwODQ3NSAwMDAwMCBuIAowMDAwMDc3NDI2IDAwMDAwIG4gCjAwMDAwMjA0OTIgMDAwMDAg biAKMDAwMDAyMDE1NyAwMDAwMCBuIAowMDAwMDE5ODIwIDAwMDAwIG4gCjAwMDAwMTk1ODcgMDAw MDAgbiAKMDAwMDAwNzM4NSAwMDAwMCBuIAowMDAwMDA3NjkyIDAwMDAwIG4gCjAwMDAwMTA0Mjkg MDAwMDAgbiAKMDAwMDAwOTI1NCAwMDAwMCBuIAowMDAwMDA5NTQ5IDAwMDAwIG4gCjAwMDAwMDg0 OTQgMDAwMDAgbiAKMDAwMDAwODcwOSAwMDAwMCBuIAowMDAwMDA4NzI4IDAwMDAwIG4gCjAwMDAw MDkwMTEgMDAwMDAgbiAKMDAwMDAwOTAzMCAwMDAwMCBuIAowMDAwMDA5MjM1IDAwMDAwIG4gCjAw MDAwMDk1NjkgMDAwMDAgbiAKMDAwMDAxMDQwOSAwMDAwMCBuIAowMDAwMDEwNDY2IDAwMDAwIG4g CjAwMDAwMTMxODQgMDAwMDAgbiAKMDAwMDAxNjY3NCAwMDAwMCBuIAowMDAwMDEzMjQxIDAwMDAw IG4gCjAwMDAwMTY2NTMgMDAwMDAgbiAKMDAwMDAxNjc5NiAwMDAwMCBuIAowMDAwMDE2OTA5IDAw MDAwIG4gCjAwMDAwMTkyOTAgMDAwMDAgbiAKMDAwMDAxOTAyMyAwMDAwMCBuIAowMDAwMDE4NzI2 IDAwMDAwIG4gCjAwMDAwMTgzNzUgMDAwMDAgbiAKMDAwMDAxODAyNSAwMDAwMCBuIAowMDAwMDE3 NzMxIDAwMDAwIG4gCjAwMDAwMTc0MzUgMDAwMDAgbiAKMDAwMDAxNzEzOSAwMDAwMCBuIAowMDAw MDE3MDc1IDAwMDAwIG4gCjAwMDAwMTcyNTYgMDAwMDAgbiAKMDAwMDAxNzMxMiAwMDAwMCBuIAow MDAwMDE3NTUyIDAwMDAwIG4gCjAwMDAwMTc2MDggMDAwMDAgbiAKMDAwMDAxNzg0NiAwMDAwMCBu IAowMDAwMDE3OTAyIDAwMDAwIG4gCjAwMDAwMTgxNDEgMDAwMDAgbiAKMDAwMDAxODE5NyAwMDAw MCBuIAowMDAwMDE4NDkyIDAwMDAwIG4gCjAwMDAwMTg1NDggMDAwMDAgbiAKMDAwMDAxODg0NCAw MDAwMCBuIAowMDAwMDE4OTAwIDAwMDAwIG4gCjAwMDAwMTkxNDAgMDAwMDAgbiAKMDAwMDAxOTE5 NiAwMDAwMCBuIAowMDAwMDE5NDA4IDAwMDAwIG4gCjAwMDAwMTk0NjQgMDAwMDAgbiAKMDAwMDAx OTcwNCAwMDAwMCBuIAowMDAwMDE5NzYwIDAwMDAwIG4gCjAwMDAwMTk5MzkgMDAwMDAgbiAKMDAw MDAxOTk5NSAwMDAwMCBuIAowMDAwMDIwMjc0IDAwMDAwIG4gCjAwMDAwMjAzMzAgMDAwMDAgbiAK MDAwMDAyMDYwOSAwMDAwMCBuIAowMDAwMDIwNjY1IDAwMDAwIG4gCjAwMDAwMjA4NjUgMDAwMDAg biAKMDAwMDAyMDkyMSAwMDAwMCBuIAowMDAwMDIxMjcwIDAwMDAwIG4gCjAwMDAwMjEzMjYgMDAw MDAgbiAKMDAwMDAyMTY2NyAwMDAwMCBuIAowMDAwMDIxNzIzIDAwMDAwIG4gCjAwMDAwMjE5MzUg MDAwMDAgbiAKMDAwMDAyMTk5MSAwMDAwMCBuIAowMDAwMDIyMTY3IDAwMDAwIG4gCjAwMDAwMjIy MjMgMDAwMDAgbiAKMDAwMDAyMjQxMSAwMDAwMCBuIAowMDAwMDIyNDY3IDAwMDAwIG4gCjAwMDAw MjI2MzkgMDAwMDAgbiAKMDAwMDAyMjY5NSAwMDAwMCBuIAowMDAwMDIyNzQyIDAwMDAwIG4gCjAw MDAwNDQ3MDkgMDAwMDAgbiAKMDAwMDA0NDczMiAwMDAwMCBuIAowMDAwMDQ0OTg3IDAwMDAwIG4g CjAwMDAwNDU2NjQgMDAwMDAgbiAKMDAwMDA2OTAxNCAwMDAwMCBuIAowMDAwMDY5MDM3IDAwMDAw IG4gCjAwMDAwNjkyODggMDAwMDAgbiAKMDAwMDA2OTgwMCAwMDAwMCBuIAowMDAwMDc2OTI5IDAw MDAwIG4gCjAwMDAwNzY5NTEgMDAwMDAgbiAKMDAwMDA3NzIwOSAwMDAwMCBuIAowMDAwMDc3NjA2 IDAwMDAwIG4gCjAwMDAwNzc2NTUgMDAwMDAgbiAKMDAwMDA3NzcwOCAwMDAwMCBuIAowMDAwMDc3 NzM4IDAwMDAwIG4gCjAwMDAwNzc3NjQgMDAwMDAgbiAKMDAwMDA3NzgwNyAwMDAwMCBuIAowMDAw MDc3ODI3IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgMTE4IC9Sb290IDYwIDAgUiAvSW5mbyAx IDAgUiAvSUQgWyA8NTMxN2IwOTQzYTNiZGJjMzQyZmJhYzQ5MmUxNGQyNjI+Cjw1MzE3YjA5NDNh M2JkYmMzNDJmYmFjNDkyZTE0ZDI2Mj4gXSA+PgpzdGFydHhyZWYKNzgwMTUKJSVFT0YK --Apple-Mail-618--863668135 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail-618--863668135-- From lear@cisco.com Wed Jun 15 10:07:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADFD21F84E8 for ; Wed, 15 Jun 2011 10:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fScA8TumaN1x for ; Wed, 15 Jun 2011 10:07:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 961A621F84E7 for ; Wed, 15 Jun 2011 10:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1198; q=dns/txt; s=iport; t=1308157657; x=1309367257; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZQJ7Jg5QXkE3tz+TayakRIKUmRdFbevARky1+2tSNiw=; b=XZOT6QGTapY9gXdP4+xljmZJP7szsqzIEBmaLLfc8Lw3oNnaPUYSJiEH 1RXV1XGFMslztifteEVIt+k0bowfG1OVuMsn//D6sAvI8PqWs3fqtB6Ld ++bRz2vCvH3FYNfhkpJNe1APtAQRTWA/Ckkszcz20eBlQ64U9eXVOnLhC M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABfm+E2Q/khL/2dsb2JhbABShEmiDXeIc6EQjSuRFYErg3GBCgSRTo9y X-IronPort-AV: E=Sophos;i="4.65,370,1304294400"; d="scan'208";a="94135116" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2011 17:07:28 +0000 Received: from dhcp-10-61-101-58.cisco.com (dhcp-10-61-101-58.cisco.com [10.61.101.58]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5FH7RsH031366; Wed, 15 Jun 2011 17:07:27 GMT Message-ID: <4DF8E6CF.9070202@cisco.com> Date: Wed, 15 Jun 2011 19:07:27 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "t.petch" References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> <4DF740E5.4030309@cs.tcd.ie><4DF7FA0D.6040201@isi.edu> <4DF8CB71.3060806@cisco.com> <000701cc2b70$0b342500$4001a8c0@gateway.2wire.net> In-Reply-To: <000701cc2b70$0b342500$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Stephen Farrell , Joe Touch Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 17:07:38 -0000 Tom, On 6/15/11 5:22 PM, t.petch wrote: > > I do not think that it is enough for us to be clear on the status of the work; > it is the other SDO that needs to be clear. > > We know how to interpret a 9 month old I-D without the word 'ietf' in > its name and with an intended status of Experimental. The ITU-T do not. You're absolutely right. We have to set the context for the ITU on the work we are mentioning, whatever that work may be. Otherwise, why mention it? > So Joe's comment that the WG should endorse the work before we > liaise it I think spot on (and I think that Stephen has taken this on > board). The key is that there be general agreement about what information is to be shared, whether it is a working group document or not. That said, one tends to be more competent when we speak of our own work. Even is work is being considered for adoption by a working group, that is also information that can be shared. > We have arcane practices and terminology that are > incomprehensible to other SDO so we have a responsibility to > make things - such as status - clear, in language that will not be > misunderstood. 100% agree! Eliot From touch@isi.edu Wed Jun 15 14:01:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEF621F8523 for ; Wed, 15 Jun 2011 14:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.481 X-Spam-Level: X-Spam-Status: No, score=-104.481 tagged_above=-999 required=5 tests=[AWL=1.518, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGxOqQmNsXCV for ; Wed, 15 Jun 2011 14:01:52 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 226EE21F8520 for ; Wed, 15 Jun 2011 14:01:52 -0700 (PDT) Received: from [192.168.121.6] ([221.148.74.90]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p5FL0vLu022277 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 15 Jun 2011 14:01:07 -0700 (PDT) Message-ID: <4DF91D87.4080506@isi.edu> Date: Wed, 15 Jun 2011 14:00:55 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Eliot Lear References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> <4DF740E5.4030309@cs.tcd.ie><4DF7FA0D.6040201@isi.edu> <4DF8CB71.3060806@cisco.com> <000701cc2b70$0b342500$4001a8c0@gateway.2wire.net> <4DF8E6CF.9070202@cisco.com> In-Reply-To: <4DF8E6CF.9070202@cisco.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 Cc: v6ops@ietf.org, Stephen Farrell Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 21:01:52 -0000 Hi, all, On 6/15/2011 10:07 AM, Eliot Lear wrote: > Tom, > > > On 6/15/11 5:22 PM, t.petch wrote: >> >> I do not think that it is enough for us to be clear on the status of the work; >> it is the other SDO that needs to be clear. >> >> We know how to interpret a 9 month old I-D without the word 'ietf' in >> its name and with an intended status of Experimental. The ITU-T do not. > > You're absolutely right. We have to set the context for the ITU on the > work we are mentioning, whatever that work may be. Otherwise, why > mention it? > >> So Joe's comment that the WG should endorse the work before we >> liaise it I think spot on (and I think that Stephen has taken this on >> board). > > The key is that there be general agreement about what information is to > be shared, whether it is a working group document or not. That said, > one tends to be more competent when we speak of our own work. Even is > work is being considered for adoption by a working group, that is also > information that can be shared. We don't dump our email discussions on the ITU , nor do we discuss with them all of the potential WG docs that are suggested during discussions (based on this thread at least). While I wouldn't hide any major surprises in the works, we should forward work that represents the IETF. WG adoption is the clear indicator of that. AFAICT, the goal is to let them know where we're going. I think the list of WG docs does that. Joe From lorenzo@google.com Wed Jun 15 15:04:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1688711E81D3 for ; Wed, 15 Jun 2011 15:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unCgsxYE5XHJ for ; Wed, 15 Jun 2011 15:04:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 205AD11E81CC for ; Wed, 15 Jun 2011 15:04:47 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p5FM4kLu011243 for ; Wed, 15 Jun 2011 15:04:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308175487; bh=C3B7r9ABLXkwhnTq8z1eVeYqc+g=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=IGi36rN1KaU/g+H4JDSDLF/+UGGn75HKrLlEhX3FF4ZEQtThC/1FKPuwxVT0o4Rdj qd6uaGapT8Lb/87IzVNsg== Received: from yxd5 (yxd5.prod.google.com [10.190.1.197]) by wpaz29.hot.corp.google.com with ESMTP id p5FM2t5D018161 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Jun 2011 15:04:45 -0700 Received: by yxd5 with SMTP id 5so735404yxd.7 for ; Wed, 15 Jun 2011 15:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Sx0AtDS4qQBeHV1Cz0eety0njh5zV69vQPBqTmabYXM=; b=coUb3J6dhr83bMkU7/fjeuqzKROPAUkEOvJNT2ymYKLRlDuxVdeVuiclCcE0Aa4Ejb t8RVft8814EL/oJhqqOw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=yUBBSylSAAcKCHUwG+mejez8USZi0Y1jZaZCCd1YYxAy5QbvsrKnYJ6VbWabpe3ZfP 3Xh0MSGtHOgfuteb2TCA== Received: by 10.151.24.10 with SMTP id b10mr182240ybj.93.1308175485107; Wed, 15 Jun 2011 15:04:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.147.16 with HTTP; Wed, 15 Jun 2011 15:04:24 -0700 (PDT) In-Reply-To: <20110615081050.70c9112a@opy.nosense.org> References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> <20110615081050.70c9112a@opy.nosense.org> From: Lorenzo Colitti Date: Wed, 15 Jun 2011 15:04:24 -0700 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=000e0cd23ef617fcdd04a5c75705 X-System-Of-Record: true Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 22:04:49 -0000 --000e0cd23ef617fcdd04a5c75705 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 14, 2011 at 3:40 PM, Mark Smith < ipng@69706e6720323030352d30312d31340a.nosense.org> wrote: > I don't know if it is intentional, however if I use Google's public > 8.8.8.8 and 8.8.4.4 resolvers, and prefer 6to4 over native IPv4 > (via /etc/gai.conf under Linux/glibc), it seems that the video content > of all youtube videos is now being delivered over IPv6. > Yes, YouTube videos are currently being served on dual-stack hostnames. The percentage of YouTube users that uses 6to4 is less than 0.02%. The percentage of YouTube users that uses native IPv6 is approximately 0.2% - over 10x more. > That said, I would argue that most or all 6to4 traffic could just as well > > use IPv4, since both parties to the communication obviously have access > to a > > public IPv4 address. What is the advantage of using 6to4 over IPv4 that > > makes it worth suffering an 80% failure rate? > > I'm having and have been having 100% success rate (or near enough to it > that I can remember) using 6to4 for a number of years, including with > an IPv6 MTU of as large as my PPPoE connection will support i.e. my > 6to4 tunnel has an IPv6 MTU of 1472. Since noticing that youtube videos > are coming over IPv6, I've paid a bit more attention to the "quality of > experience" I've had, and have not found any reasons to change my > preference back to native IPv4 instead of 6to4. > Sure - you're one of the 80% for whom it works. But that wasn't my question - my question was "what is the advantage?" You said that you have near enough 100% success rate, but I bet that your IPv4 success rate is near enough 100% as well. So what are you gaining by using 6to4 to talk to YouTube? --000e0cd23ef617fcdd04a5c75705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 14, 2011 at 3:40 PM, Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense= .org> wrote:
I don't know if it is intentional, = however if I use Google's public
8.8.8.8 and 8.8.4.4 resolvers, and prefer 6to4 over native IPv4
(via /etc/gai.conf under Linux/glibc), it seems that the video content
of all youtube videos is now being delivered over IPv6.

Yes, YouTube videos are currently being served on dual-sta= ck hostnames.=A0The percentage of YouTube users that uses 6to4 is less than= 0.02%. The percentage of YouTube users that uses native IPv6 is approximat= ely 0.2% - over 10x more.

> That said, I would argue that most or all 6to4 traffic could just= as well
> use IPv4, since both parties to the communication obviously have acces= s to a
> public IPv4 address. What is the advantage of using 6to4 over IPv4 tha= t
> makes it worth suffering an 80% failure rate?

I'm having and have been having 100% success rate (or near enough= to it
that I can remember) using 6to4 for a number of years, including with
an IPv6 MTU of as large as my PPPoE connection will support i.e. my
6to4 tunnel has an IPv6 MTU of 1472. Since noticing that youtube videos
are coming over IPv6, I've paid a bit more attention to the "quali= ty of
experience" I've had, and have not found any reasons to change my<= br> preference back to native IPv4 instead of 6to4.

Sure - you're one of the 80% for whom it wo= rks. But that wasn't my question - my question was "what is the ad= vantage?" You said that you have near enough 100% success rate, but I = bet that your IPv4 success rate is near enough 100% as well. So what are yo= u gaining by using 6to4 to talk to YouTube?
--000e0cd23ef617fcdd04a5c75705-- From moore@network-heretics.com Wed Jun 15 15:58:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAED11E80C7; Wed, 15 Jun 2011 15:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9p6kXiYulKg; Wed, 15 Jun 2011 15:58:45 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id E18EA11E80A0; Wed, 15 Jun 2011 15:58:44 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id BA06220E43; Wed, 15 Jun 2011 18:58:43 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 15 Jun 2011 18:58:43 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=o9snRecj8YwuD488YJkkVMGcVEk=; b=cPw+eTuGU5/5oVSfudKPFkg4leVBYz1vd7PXKpDwlHMQ3fWI/3buiB/YjHEJpPsh3jyWkjhjfjbUcqpVU12e6g8gYLlGSPSAbyHhx6Ia7CrGmY6TJ+VJqNaPJXrjP50CQqss5yCW2sM+karwj3ymrW497ar9DNrl2d22M6iyUM8= X-Sasl-enc: y+AH5u7sLlqsqTewhgvm6vOzXMmFsqZbJJLE46/q1uUG 1308178723 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id A055F440D1D; Wed, 15 Jun 2011 18:58:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Wed, 15 Jun 2011 18:58:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 22:58:45 -0000 On Jun 14, 2011, at 1:59 PM, Lorenzo Colitti wrote: > That said, I would argue that most or all 6to4 traffic could just as = well use IPv4, since both parties to the communication obviously have = access to a public IPv4 address. What is the advantage of using 6to4 = over IPv4 that makes it worth suffering an 80% failure rate? it can communicate with hosts that have only IPv6, it can communicate with hosts that are stuck behind a single IPv4 = address (if the router acts as a 6to4 gateway) without a NAT being in = the way, it can be used to develop and test IPv6 applications without having to = build a special-purpose network, it can be used to deploy applications now that already support IPv6 and = so are in some sense future-proofed, it can be deployed on either a single host or a network again, trying to judge how well 6to4 works by how well it works with web = sites that also support IPv4 is entirely missing the point. Keith From lorenzo@google.com Wed Jun 15 16:10:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817B211E817E for ; Wed, 15 Jun 2011 16:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQOPxpsjTiFR for ; Wed, 15 Jun 2011 16:10:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3B08311E8178 for ; Wed, 15 Jun 2011 16:10:52 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p5FNAYa8010502 for ; Wed, 15 Jun 2011 16:10:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308179435; bh=NlNp/hwNjfNH2eCut373Ij+OFBw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=yUfywqdpURQC4l9tgyjRbPjxOZ7D43V91Mwz7DW/roQr41ix8pRH/Qptph4192Jne 5NCzkTbCuAmaZQLk6LjUA== Received: from yxl31 (yxl31.prod.google.com [10.190.3.223]) by hpaq11.eem.corp.google.com with ESMTP id p5FNAWad009391 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Jun 2011 16:10:33 -0700 Received: by yxl31 with SMTP id 31so857015yxl.27 for ; Wed, 15 Jun 2011 16:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=W/jKYruZj85BFAEECs41mPi8QVatHKPJu6upyg8Iyo8=; b=aE5ZPAkd9Qz/Qtg5ve53huYgovo1TcZnEpB2Lpg7US2BEiYbT3JguZwA44Jt3cW5g6 tpRsTCFMJY7DycAbx+3g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=W7kLAXBnZnWUnmg39QiYA/DK1pJi4Gdio2LOlt3TvGSQJMcej/DGOKsqCXiOpPAFDs oLP4RPYncEWasFg4tktg== Received: by 10.150.7.15 with SMTP id 15mr211196ybg.378.1308179432104; Wed, 15 Jun 2011 16:10:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.147.16 with HTTP; Wed, 15 Jun 2011 16:10:12 -0700 (PDT) In-Reply-To: References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> From: Lorenzo Colitti Date: Wed, 15 Jun 2011 16:10:12 -0700 Message-ID: To: Keith Moore Content-Type: multipart/alternative; boundary=000e0cd287885a63de04a5c842ef X-System-Of-Record: true Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 23:10:53 -0000 --000e0cd287885a63de04a5c842ef Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 15, 2011 at 3:58 PM, Keith Moore wrote: > > That said, I would argue that most or all 6to4 traffic could just as well > use IPv4, since both parties to the communication obviously have access to a > public IPv4 address. What is the advantage of using 6to4 over IPv4 that > makes it worth suffering an 80% failure rate? > > > it can communicate with hosts that have only IPv6, > it can communicate with hosts that are stuck behind a single IPv4 address > (if the router acts as a 6to4 gateway) without a NAT being in the way, > it can be used to develop and test IPv6 applications without having to > build a special-purpose network, > it can be used to deploy applications now that already support IPv6 and so > are in some sense future-proofed, > it can be deployed on either a single host or a network > ... about 80% of the time. I would argue that cases 1, 3, 4, 5, and 6 can be solved more reliably using configured tunnels, and that case 2 is today solved more reliably, and in more cases (e.g., when no public IPv4 address is available at the border) by the various NAT traversal mechanisms that are implemented in applications. But I think we're just going around in circles here. --000e0cd287885a63de04a5c842ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 15, 2011 at 3:58 PM, Keith Moore <moore@netw= ork-heretics.com> wrote:
> That said, I would argue that most or all 6to4 traff= ic could just as well use IPv4, since both parties to the communication obv= iously have access to a public IPv4 address. What is the advantage of using= 6to4 over IPv4 that makes it worth suffering an 80% failure rate?


it can communicate with hosts that have only IPv6,
it can communicate with hosts that are stuck behind a single IPv4 address (= if the router acts as a 6to4 gateway) without a NAT being in the way,
it can be used to develop and test IPv6 applications without having to buil= d a special-purpose network,
it can be used to deploy applications now that already support IPv6 and so = are in some sense future-proofed,
it can be deployed on either a single host or a network

... about 80% of the time.

I woul= d argue that cases 1, 3, 4, 5, and 6 can be solved more reliably using conf= igured tunnels, and that case 2 is today solved more reliably, and in more = cases (e.g., when no public IPv4 address is available at the border) by the= various NAT traversal mechanisms that are implemented in applications. But= I think we're just going around in circles here.
--000e0cd287885a63de04a5c842ef-- From moore@network-heretics.com Wed Jun 15 16:38:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9412F11E81E4; Wed, 15 Jun 2011 16:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTZ5-HuAyHmo; Wed, 15 Jun 2011 16:38:48 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 767AB11E81DE; Wed, 15 Jun 2011 16:38:48 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 185F120DD0; Wed, 15 Jun 2011 19:38:47 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 15 Jun 2011 19:38:48 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=23s1RC2Qa0oRgmgeHyE2HsAfiuo=; b=ot2u8rswrHj+0wtG1UZNRatImEtFTceeHYKuOUxv7/3dORCpv9DvgDQx52HKbrP1dK6I3tNL/zMXfaQagrPAHDmRdzRyC2xJQGii3Ry3bkk03DcPK/SyOSyk11ObBS+BemioTuEFdTioHEKiGkBW+f3Cw0e2aWiUbbSWP2KS1F8= X-Sasl-enc: QL9uBjIAB1xShj4IOG00pcdk+k6Im86mbwVdyBPIoQ/f 1308181126 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 637AB4425A2; Wed, 15 Jun 2011 19:38:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-9--838556222 From: Keith Moore In-Reply-To: Date: Wed, 15 Jun 2011 19:38:45 -0400 Message-Id: <11B87B4E-6F6F-4ABF-B5B9-BDA177E2FD7E@network-heretics.com> References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 23:38:49 -0000 --Apple-Mail-9--838556222 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 15, 2011, at 7:10 PM, Lorenzo Colitti wrote: > On Wed, Jun 15, 2011 at 3:58 PM, Keith Moore = wrote: > > That said, I would argue that most or all 6to4 traffic could just as = well use IPv4, since both parties to the communication obviously have = access to a public IPv4 address. What is the advantage of using 6to4 = over IPv4 that makes it worth suffering an 80% failure rate? >=20 >=20 > it can communicate with hosts that have only IPv6, > it can communicate with hosts that are stuck behind a single IPv4 = address (if the router acts as a 6to4 gateway) without a NAT being in = the way, > it can be used to develop and test IPv6 applications without having to = build a special-purpose network, > it can be used to deploy applications now that already support IPv6 = and so are in some sense future-proofed, > it can be deployed on either a single host or a network >=20 > ... about 80% of the time. A single figure doesn't really describe the situation. The = successes/failures aren't independent of one another. It's not that you = get only an 80% probability of things working on every connection. It's = more like, it either works fairly well for what you need it to do, or it = doesn't. Again, don't assume that this is like the web and the connections are = mostly client-to-server, or one source to large numbers of different = destinations. > I would argue that cases 1, 3, 4, 5, and 6 can be solved more reliably = using configured tunnels, There are lots of different tunneling methods each with strengths and = weaknesses. What you probably do in practice is try one, and if that = doesn't work for your purposes, try another. 6to4 is very easy to try, = and it often works.=20 Keith --Apple-Mail-9--838556222 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Wed, Jun 15, 2011 at 3:58 = PM, Keith Moore <moore@network-heretics.com&= gt; wrote:
> That said, I would argue that most or all 6to4 = traffic could just as well use IPv4, since both parties to the = communication obviously have access to a public IPv4 address. What is = the advantage of using 6to4 over IPv4 that makes it worth suffering an = 80% failure rate?


it can communicate with hosts that have only IPv6,
it can communicate with hosts that are stuck behind a single IPv4 = address (if the router acts as a 6to4 gateway) without a NAT being in = the way,
it can be used to develop and test IPv6 applications without having to = build a special-purpose network,
it can be used to deploy applications now that already support IPv6 and = so are in some sense future-proofed,
it can be deployed on either a single host or a = network

... about 80% of the = time.

A single figure doesn't = really describe the situation.   The successes/failures aren't = independent of one another.  It's not that you get only an 80% = probability of things working on every connection.  It's more like, = it either works fairly well for what you need it to do, or it = doesn't.

Again, don't assume that this is like = the web and the connections are mostly client-to-server, or one source = to large numbers of different destinations.

I would argue that cases = 1, 3, 4, 5, and 6 can be solved more reliably using configured tunnels, =

There are lots of different = tunneling methods each with strengths and weaknesses.   What you = probably do in practice is try one, and if that doesn't work for your = purposes, try another.  6to4 is very easy to try, and it often = works. 

Keith

= --Apple-Mail-9--838556222-- From marka@isc.org Wed Jun 15 18:22:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D55711E80C7; Wed, 15 Jun 2011 18:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coumNOmqaTWv; Wed, 15 Jun 2011 18:22:05 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 7953C11E8080; Wed, 15 Jun 2011 18:22:05 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id A48C45F9861; Thu, 16 Jun 2011 01:21:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 7D383216C7B; Thu, 16 Jun 2011 01:21:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 63F3510CDCB3; Thu, 16 Jun 2011 11:21:40 +1000 (EST) To: Lorenzo Colitti From: Mark Andrews References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> In-reply-to: Your message of "Wed, 15 Jun 2011 16:10:12 MST." Date: Thu, 16 Jun 2011 11:21:40 +1000 Message-Id: <20110616012140.63F3510CDCB3@drugs.dv.isc.org> Cc: "v6ops@ietf.org WG" , Keith Moore , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 01:22:06 -0000 In message , Lorenzo Colitti writes: > On Wed, Jun 15, 2011 at 3:58 PM, Keith Moore wrot > e: > > > > That said, I would argue that most or all 6to4 traffic could just as well > > use IPv4, since both parties to the communication obviously have access to > a > > public IPv4 address. What is the advantage of using 6to4 over IPv4 that > > makes it worth suffering an 80% failure rate? > > > > > > it can communicate with hosts that have only IPv6, > > it can communicate with hosts that are stuck behind a single IPv4 address > > (if the router acts as a 6to4 gateway) without a NAT being in the way, > > it can be used to develop and test IPv6 applications without having to > > build a special-purpose network, > > it can be used to deploy applications now that already support IPv6 and so > > are in some sense future-proofed, > > it can be deployed on either a single host or a network > > ... about 80% of the time. Or 99.999% of the time once you get it setup. The problem isn't 6to4, it's *automatic* 6to4. > I would argue that cases 1, 3, 4, 5, and 6 can be solved more reliably using > configured tunnels, and that case 2 is today solved more reliably, and in > more cases (e.g., when no public IPv4 address is available at the border) by > the various NAT traversal mechanisms that are implemented in applications. > But I think we're just going around in circles here. Which often times requires special software to be installed. Tunnels are a lot more hassle to setup and yes I've used both so I know. 6to4 historic is throwing the baby out with the bath water. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From lorenzo@google.com Wed Jun 15 18:43:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AFB11E818A for ; Wed, 15 Jun 2011 18:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlwWiLtrQtkk for ; Wed, 15 Jun 2011 18:43:47 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id DE96D11E8181 for ; Wed, 15 Jun 2011 18:43:46 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p5G1hj38002833 for ; Wed, 15 Jun 2011 18:43:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308188625; bh=Z2zFNLo3NCiexyG3IwpGEjjL5fE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=dvTdThjWSUD7WVpxj7mDCxQDZZvfiy4Xscfmts6U6ryqCF5lVVBxOB/WmsP2N7tql 9Nhkx9RE6boqklmJ8+luQ== Received: from pwj3 (pwj3.prod.google.com [10.241.219.67]) by hpaq14.eem.corp.google.com with ESMTP id p5G1hBOE031647 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Jun 2011 18:43:44 -0700 Received: by pwj3 with SMTP id 3so360254pwj.29 for ; Wed, 15 Jun 2011 18:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=btjCGuUpmdoLv4umMV9KJWuAtCOM0tJFqMU7RTtHyao=; b=gMFiq8MDfW3s9bv4cyAl1u1KThHMG9PIf38pZu7T6jhisa79TDn0Gkj3lpaEW7Ig/j 8Ug2CblOkGV+i1wnvECw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=SMGNdyRYFWCOL6AT1PE0EOP+se+Ov9NSJ+GwUQiijGICWssEEzXpxEgFuVzGRvlspl gABYGrwEAWN89cKH1SPQ== Received: by 10.142.231.2 with SMTP id d2mr60230wfh.262.1308188623524; Wed, 15 Jun 2011 18:43:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.216.13 with HTTP; Wed, 15 Jun 2011 18:43:23 -0700 (PDT) In-Reply-To: <20110616012140.63F3510CDCB3@drugs.dv.isc.org> References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> <20110616012140.63F3510CDCB3@drugs.dv.isc.org> From: Lorenzo Colitti Date: Wed, 15 Jun 2011 18:43:23 -0700 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=000e0cd17f2034553404a5ca66f2 X-System-Of-Record: true Cc: "v6ops@ietf.org WG" , Keith Moore , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 01:43:47 -0000 --000e0cd17f2034553404a5ca66f2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 15, 2011 at 6:21 PM, Mark Andrews wrote: > > ... about 80% of the time. > > Or 99.999% of the time once you get it setup. The problem isn't 6to4, it's > *automatic* 6to4. > No, because you often end up being dependent on the whims of BGP and third-party relays for your return path. Sure, if you have enough control over routing in a closed network, you can make sure the right relays are used. But in that case, why not use configured tunnels? > 6to4 historic is throwing the baby out with the bath water. > On this we know we disagree. --000e0cd17f2034553404a5ca66f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 15, 2011 at 6:21 PM, Mark Andrews <marka@isc.org><= /span> wrote:
> ... about 80% of the time.

Or 99.999% of the time once you get it setup. =A0The problem isn'= t 6to4, it's
*automatic* 6to4.

No, because you often= end up being dependent on the whims of BGP and third-party relays for your= return path. Sure, if you have enough control over routing in a closed net= work, you can make sure the right relays are used. But in that case, why no= t use configured tunnels?
=A0
6to4 historic is throwing the baby out with the bath wate= r.

On this we know we disagree.
=
--000e0cd17f2034553404a5ca66f2-- From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Jun 15 19:45:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D1211E8136; Wed, 15 Jun 2011 19:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pxEo2HRLcHH; Wed, 15 Jun 2011 19:45:22 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id A2CD311E811E; Wed, 15 Jun 2011 19:45:21 -0700 (PDT) Received: from 114-30-99-224.ip.adam.com.au ([114.30.99.224] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QX2a6-0005ce-BO; Thu, 16 Jun 2011 12:15:18 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id C07013B33E; Thu, 16 Jun 2011 12:15:17 +0930 (CST) Date: Thu, 16 Jun 2011 12:15:17 +0930 From: Mark Smith To: Lorenzo Colitti Message-ID: <20110616121517.079ba496@opy.nosense.org> In-Reply-To: References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> <20110616012140.63F3510CDCB3@drugs.dv.isc.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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 WG" , Keith Moore , IETF Discussion Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 02:45:22 -0000 On Wed, 15 Jun 2011 18:43:23 -0700 Lorenzo Colitti wrote: > On Wed, Jun 15, 2011 at 6:21 PM, Mark Andrews wrote: > > > > ... about 80% of the time. > > > > Or 99.999% of the time once you get it setup. The problem isn't 6to4, it's > > *automatic* 6to4. > > > > No, because you often end up being dependent on the whims of BGP and > third-party relays for your return path. If you generalise that statement a bit, "No, because you often end up being dependent on the whims of BGP and third-party routers for your return path." you're describing the trust inherent in the operation of the Internet, both for IPv4 and IPv6. Yes there are some incompetent operators out there, but most of them aren't - they wouldn't keep their jobs otherwise, and the Internet would break more often than it does. I can only remember one instance of 6to4 relay breakage in the last 5 years, and IIRC that was fixed within 24 hours. People seem to be using a very coarse "less than absolute 100% success means total technology failure" to state that 6to4 as a whole is unreliable. Where is the data to back this up? Did Geoff Huston do any more detailed analysis of the 6to4 data, other than measuring success verses failure rates for 6to4 connections? Could I, for example, have warped his 6to4 failure rates during the test if I used all my 2^16 x 2^64 IPv6 6to4 addresses to purposely create excessive failed 6to4 connections apparently from many different hosts? I'm certainly not saying that exists in Geoff's data, rather asking how do we know that it doesn't? I have a vested interest in anycast 6to4 continuing to exist, because it has been as reliable as any other Internet technology I use. I also think it has some latency advantages over configured tunnels because my IPv6 traffic enters the IPv6 Internet where ever the closest 6to4 relay reachable via IPv4 is. That used to be in Europe (around 14000 Km from me) when I first started using 6to4, now it is only around 3000 Km, and as my ISP is going to deploy a 6to4 relay in the near future, will be around 8Km away. These changes have and will continue to be transparent on my end. I'd also get these latency benefits if I was changing my IPv4 Internet points of attachment, such as if I were travelling internationally. Anycast 6to4 also tends to distribute the IPv6 traffic load better across all the 6to4 globally gateways, instead of concentrating it at likely lower number of configured tunnel entry/exit points. Over time, increased IPv6 traffic will become a disincentive to running a configured tunnel entry/exit point because people will continue to use it even if there is a more local configured tunnel or 6to4 relay they could be using. If people use anycast 6to4, then they inherently get lower latency as a closer one becomes available, and 6to4 relay operators will see lower traffic load without intervention as more 6to4 relays are deployed. > Sure, if you have enough control > over routing in a closed network, you can make sure the right relays are > used. But in that case, why not use configured tunnels? > > > > 6to4 historic is throwing the baby out with the bath water. > > > > On this we know we disagree. From gert@space.net Wed Jun 15 23:51:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E055D11E8086 for ; Wed, 15 Jun 2011 23:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yNDacIdIFks for ; Wed, 15 Jun 2011 23:51:33 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8148411E8078 for ; Wed, 15 Jun 2011 23:51:31 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id B3E01F8160 for ; Thu, 16 Jun 2011 08:51:26 +0200 (CEST) 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 9C976F8182 for ; Thu, 16 Jun 2011 08:51:26 +0200 (CEST) Received: (qmail 78884 invoked by uid 1007); 16 Jun 2011 08:51:26 +0200 Date: Thu, 16 Jun 2011 08:51:26 +0200 From: Gert Doering To: Mark Smith Message-ID: <20110616065126.GB45955@Space.Net> References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> <20110616012140.63F3510CDCB3@drugs.dv.isc.org> <20110616121517.079ba496@opy.nosense.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110616121517.079ba496@opy.nosense.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org WG" , IETF Discussion , Keith Moore Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 06:51:37 -0000 Hi, On Thu, Jun 16, 2011 at 12:15:17PM +0930, Mark Smith wrote: > I have a vested interest in anycast 6to4 continuing to exist, This actually brings up a good argument: are you going to pay for us to run our 6to4 relay? not that the cost of it is high, but there is cost to it - to make sure it keeps working, to monitor the system for overload, etc. Our customers don't really need it (because we have native IPv6), we're offering this for free to benefit users on the other side that do not have native IPv6, but insist on not using IPv4. And this also points out why anycasted 6to4 is necessarily(!) less reliable than those other Internet technologies that you have mentioned - because those that run the relays usually have no financial interest in doing so. So if it breaks, it will take longer to notice and even longer to fix than for something that directly affects paying customers. 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 ipng@69706e6720323030352d30312d31340a.nosense.org Thu Jun 16 00:35:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EEE11E808C; Thu, 16 Jun 2011 00:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPDoCEvHMn6k; Thu, 16 Jun 2011 00:35:55 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 56BC211E807E; Thu, 16 Jun 2011 00:35:55 -0700 (PDT) Received: from 114-30-99-224.ip.adam.com.au ([114.30.99.224] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QX77C-0005Jj-Ne; Thu, 16 Jun 2011 17:05:46 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 463303B33E; Thu, 16 Jun 2011 17:05:46 +0930 (CST) Date: Thu, 16 Jun 2011 17:05:45 +0930 From: Mark Smith To: Gert Doering Message-ID: <20110616170545.6f926f2a@opy.nosense.org> In-Reply-To: <20110616065126.GB45955@Space.Net> References: <20110610161806.99D1618C0F6@mercury.lcs.mit.edu> <20110616012140.63F3510CDCB3@drugs.dv.isc.org> <20110616121517.079ba496@opy.nosense.org> <20110616065126.GB45955@Space.Net> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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 WG" , IETF Discussion , Keith Moore Subject: Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 07:35:56 -0000 Hi Gert, On Thu, 16 Jun 2011 08:51:26 +0200 Gert Doering wrote: > Hi, > > On Thu, Jun 16, 2011 at 12:15:17PM +0930, Mark Smith wrote: > > I have a vested interest in anycast 6to4 continuing to exist, > > This actually brings up a good argument: > > are you going to pay for us to run our 6to4 relay? > > > not that the cost of it is high, but there is cost to it - to make sure > it keeps working, to monitor the system for overload, etc. > It was a conscious decision of yours to announce it globally, so you've made a conscious decision to provide it to people for free and to take on the operational responsibilities of doing so. If you become unhappy with accepting those costs without corresponding compensation, withdraw the 6to4 anycast IPv4 address from the global route table, and people like me would move onto another 6to4 relay automatically. I certainly don't take for granted people's generosity in providing them to global users, however I think that if you choose to do something charitable, you have then created an obligation on yourself to do it well and reliably. Most people both understand and deliver on that obligation. I've actually become more conscious of this lack of financial incentive since I've noticed that youtube videos are coming to me over IPv6. That's what prompted me to ask if my ISP was planning to deploy a 6to4 relay soon as an interim step towards their native service. > Our customers don't really need it (because we have native IPv6), we're > offering this for free to benefit users on the other side that do not > have native IPv6, but insist on not using IPv4. > > > And this also points out why anycasted 6to4 is necessarily(!) less > reliable than those other Internet technologies that you have mentioned - > because those that run the relays usually have no financial interest in > doing so. So if it breaks, it will take longer to notice and even longer > to fix than for something that directly affects paying customers. > Actually, a broken local 6to4 relay is likely to be impacting your paying customers too as it is their local 6to4 relay. Your arguments are not specific to 6to4 though - I think they apply to anybody providing a free configured tunnel service too. In some cases they apply more so - the administrative effort to support automated provisioning of configured tunnels is greater than that involved in setting up an anycast 6to4 relay. Regards, Mark. From jeanmichel.combes@gmail.com Thu Jun 16 10:13:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AE611E8190; Thu, 16 Jun 2011 10:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.12 X-Spam-Level: X-Spam-Status: No, score=-103.12 tagged_above=-999 required=5 tests=[AWL=-0.121, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOZy-VvtwQba; Thu, 16 Jun 2011 10:13:32 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DCBC311E81EB; Thu, 16 Jun 2011 10:13:31 -0700 (PDT) Received: by ywp31 with SMTP id 31so1246731ywp.31 for ; Thu, 16 Jun 2011 10:13:31 -0700 (PDT) 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=DCbxoJLeVhmeEYEMgTJMQVTJDsOlqNdJNkG0OLfWjmw=; b=L4Eu4TCWwS+OBR06nwLAGDHFPYfY8gebWdGnlkuJLnadBuzraFP5rPvQB1RpdO/53X CBrnZgVlXMJLLFoM+nW8DkFkiBY2rVF47BbMseP9Q6hbK9rdIfxszce0PYaOkLOAt8sj oYEGaDmLZH0sHkWR5RgLpjRYpaMMgAS+TVfmE= 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=rU41GUtbaHAwgtbGAa/1iVSG5oNsEidJM4YL2Adwavaj6jOXE+HIcUREtu7dH8vu4y JCkaQF4QUH/cS7Zm/maZOWmGDiONUAFfsUGKYpGfDyhUbBsEsoj8Mf8Rhr+Z7Ao4CgFC u6PY+tdmXiUq+KNyktIIUWFp7r9DNNHspw0Cs= MIME-Version: 1.0 Received: by 10.236.44.39 with SMTP id m27mr1714210yhb.92.1308244410965; Thu, 16 Jun 2011 10:13:30 -0700 (PDT) Received: by 10.147.83.20 with HTTP; Thu, 16 Jun 2011 10:13:30 -0700 (PDT) In-Reply-To: <4DF291D0.7080707@gont.com.ar> References: <4DF291D0.7080707@gont.com.ar> Date: Thu, 16 Jun 2011 19:13:30 +0200 Message-ID: From: Jean-Michel Combes To: Fernando Gont Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 17:13:32 -0000 Hi, I've read quickly these two drafts. Here are some comments/questions: o draft-gont-v6ops-ra-guard-evasion IMHO, this draft should update RFC 6105 (If so, RFC6105 reference should move from Informative References section to the Normative References one). Just a comment about your example for the fragmentation case with 2 Destination extensions: from RFC2460 (section 4.1), this only occurs when there is also a Routing Header extension, so I have to add a RH in your example (better chance to get a fragmentation :)) o draft-gont-6man-nd-extension-headers IMHO, this is not a good idea to forbid the use of IPv6 extension with NDP messages, especially when the reason is partially based on implementation issues (i.e. the implementation is not able to process an IPv6 packet): today, there is no real use of Extension header with NDP but, tomorrow, if we need such an use for a solution, what will happen? Regarding the fragmentation, is it not possible for the RA-Guard device to reassemble the fragments and so to be able to check whether this a RA message or not? Thanks in advance for your reply. Best regards. JMC. 2011/6/10 Fernando Gont : > Hi, > > Some folks have expressed (both on-list and off-list) that they would > prefer a less agressive solution for the RA-Guard evasion vulnerability. > So I'd like to hear comments about the possible alternatives.. > > The current I-Ds (draft-gont-6man-nd-extension-headers and > draft-gont-v6ops-ra-guard-evasion) basically take this approach: > > * Prohibit use of extension headers in ND messages. A host > implementation must not produce these packets, and must discard them if > it receives them > * This results in a RA-Guard implementation that is as simple as > possible (it only has to look at the header following the fixed IPv6 > header). > > > A more relaxed approach would be as follows: > * Extension headers are allowed with ND messages. > * If the packet is fragmented, the upper-layer header (ICMPv6 in this > case) must be present in the first fragment (i.e., hosts must not > generate packets that violate this requirement, and must discard them if > they receive them). > * Possibly have the RA-Guard box enforce a limit on the maximum number > of extension headers that it will process (e.g., if after jumping to > the, say 10th header the upper-layer header is not found, drop the packet) > * This approach is less aggressive than the one proposed in the > aforementioned I-Ds (i.e., more flexibility), but of course would also > mean that the RA-Guard implementation would need to follow the header > chain, thus leading to increased complexity, and possible performance > issues. > > Any comments/thoughts will be very much appreciated. > > 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 > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From jeanmichel.combes@gmail.com Thu Jun 16 10:16:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB7511E823D; Thu, 16 Jun 2011 10:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.402 X-Spam-Level: X-Spam-Status: No, score=-103.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKSpJH6FeqlW; Thu, 16 Jun 2011 10:16:14 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1CF11E8232; Thu, 16 Jun 2011 10:16:06 -0700 (PDT) Received: by gxk19 with SMTP id 19so1247670gxk.31 for ; Thu, 16 Jun 2011 10:16:03 -0700 (PDT) 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=k9ND3wuRCnGHY9SssvANQ9nmt5BKmHeQ1ZoMGE2u/UE=; b=DV1sHVYBaDVveKUOBzm9G+ykwGjkEi92uc6Lh9mmKjfeA7hN7mR01tqPb+82MDkRux 4zFWfG3g3s0qV3AS+3oBMJjtyzp+O+n6pxAvllxh3/I3Twt035ZSFRwN14adur2GOL3n 8sHpnVLGdPBqwR4ZcURsaHTAH7bBRkZ8eczu0= 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=T6WkKiPRoXMXsEzPxk2SIrsLGII6rRxL1S/SueLh5pMR2fJwgn9TzimitlImIoL7zo PgtgC3CbJz8CESkIOx86lSi3Y59rjcdy2McvU9hDQcAYMfCK6Hzg3LKuDcKZZFc8yR0a vYlOA4JKhu4yQsSr1cf7pD/DemcnQSO8BxxOg= MIME-Version: 1.0 Received: by 10.151.92.2 with SMTP id u2mr1423711ybl.209.1308244563225; Thu, 16 Jun 2011 10:16:03 -0700 (PDT) Received: by 10.147.83.20 with HTTP; Thu, 16 Jun 2011 10:16:03 -0700 (PDT) In-Reply-To: References: <4DF291D0.7080707@gont.com.ar> <4DF69180.6050902@inex.ie> <701DCBC2-E1B6-420A-B258-504589335A20@nominum.com> Date: Thu, 16 Jun 2011 19:16:03 +0200 Message-ID: From: Jean-Michel Combes To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 17:16:16 -0000 Hi, Regarding DHCP SAVI, this is not the main goal of this solution but a side effect. Best regards. JMC. 2011/6/14 Mikael Abrahamsson : > On Mon, 13 Jun 2011, Ted Lemon wrote: > >> On Jun 13, 2011, at 3:38 PM, Nick Hilliard wrote: >>> >>> dhcpv6 suffers from exactly the same problem. =A0Are there plans to >>> introduce dhcpv6-guard? >> >> Nobody's proposed it. > > > > I'd be surprised if implementations of this wouldn't also have some kind = of > idea or concept of "client ports" and "server ports"? > > -- > Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From fred@cisco.com Thu Jun 16 11:06:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E304221F8476 for ; Thu, 16 Jun 2011 11:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.691 X-Spam-Level: X-Spam-Status: No, score=-110.691 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVOZTrvtU3uW for ; Thu, 16 Jun 2011 11:06:00 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 13DE621F8475 for ; Thu, 16 Jun 2011 11:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=409; q=dns/txt; s=iport; t=1308247560; x=1309457160; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=niIx1IjXF7INl5FrpqQjxFQOBgtiW0XDDEgd6PU9AZE=; b=KI/0yrutOtUmnOP6mEO0BNc09mtzbCh0zIV7r2kwIt62gpK+tyEMR5mP RsPEp1op52Z125OsxNIXBo7GHQpBVasyO7IXGUAlUYy7MtbNuaM3MGCdW XbOYcDwyuSmQwUUBWXiykpIHRr3oREZ5eZatptQxIIAgLYP7v4xE6AHOS c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKFF+k2rRDoJ/2dsb2JhbABSpmJ3q1ueHYYnBIcdijyEXIs6 X-IronPort-AV: E=Sophos;i="4.65,376,1304294400"; d="scan'208";a="714948049" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 16 Jun 2011 18:05:54 +0000 Received: from Freds-Computer.local (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5GI5lA8021946; Thu, 16 Jun 2011 18:05:53 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 16 Jun 2011 11:05:54 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 16 Jun 2011 11:05:54 -0700 From: Fred Baker Date: Thu, 16 Jun 2011 11:05:37 -0700 Message-Id: <380CCD7A-E4E5-4A51-81E8-11E8228C67C1@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Ron Bonica Subject: [v6ops] Departure of Kurt Lindqvist X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 18:06:01 -0000 For your information - Kurtis advised us last night that he is resigning = as working group co-chair. His duties at Netnod have consumed his time = over the past couple of years, and he finds himself at a point that = calls for simplifying his life. Speaking for the chairs, we appreciate = his contributions over the years, hope he will continue as a contributor = and participant, and wish him well.= From arturo.servin@gmail.com Thu Jun 16 12:46:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1514D11E8248; Thu, 16 Jun 2011 12:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUzoqxHcLXX0; Thu, 16 Jun 2011 12:46:35 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D308811E8205; Thu, 16 Jun 2011 12:46:34 -0700 (PDT) Received: by qyk38 with SMTP id 38so163283qyk.10 for ; Thu, 16 Jun 2011 12:46:34 -0700 (PDT) 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=gVKk+zGpYOdVOm4USOuo1rcibgEwxg0TrlYS79ATUzE=; b=QLLvaNSBiO8kE1zwTEk0+G0a9elQfcLSIrGsG/3xfUuWtZfxnvIzekmPiukup/2Cpn LoxSTcv14RsJq+3YEBLL4RK6MH6DC/M2Tn5L5V5G9Y486tBguTVopdKFnobjqiSacMSL xQgv7ONBleMJLLOh3lWJy1s8LWCBgyIALIMTM= 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=kcU5SF2X5L1cxIRJ8Kb8moeVnDSVxdfVbTB1fIaMQQlGxNRkCGzbt8c8dxbGBXTGS3 zxOuwfER5o8T6YHpFHD56M7Ii8Io/Y8WR/x70Xps8PLiuvsg33DLqmR1/BVr3vFFqbm4 0PlB8lw7l13lMz+izkMIH0WdRIrClx+cPeIuY= Received: by 10.224.211.67 with SMTP id gn3mr1046501qab.16.1308253594154; Thu, 16 Jun 2011 12:46:34 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy ([200.7.85.188]) by mx.google.com with ESMTPS id u15sm1353982qcq.0.2011.06.16.12.46.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2011 12:46:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Thu, 16 Jun 2011 16:46:27 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <351EBA42-0077-4AAD-8D4C-D2880B81FBC6@gmail.com> References: <4DF291D0.7080707@gont.com.ar> To: Jean-Michel Combes X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 19:46:36 -0000 Jean-Michel, On 16 Jun 2011, at 14:13, Jean-Michel Combes wrote: > Hi, >=20 > I've read quickly these two drafts. Here are some comments/questions: >=20 > o draft-gont-v6ops-ra-guard-evasion >=20 > IMHO, this draft should update RFC 6105 (If so, RFC6105 reference > should move from Informative References section to the Normative > References one). > Just a comment about your example for the fragmentation case with 2 > Destination extensions: from RFC2460 (section 4.1), this only occurs > when there is also a Routing Header extension, so I have to add a RH > in your example (better chance to get a fragmentation :)) >=20 > o draft-gont-6man-nd-extension-headers >=20 > IMHO, this is not a good idea to forbid the use of IPv6 extension with > NDP messages, especially when the reason is partially based on > implementation issues (i.e. the implementation is not able to process > an IPv6 packet): today, there is no real use of Extension header with > NDP but, tomorrow, if we need such an use for a solution, what will > happen? See below > Regarding the fragmentation, is it not possible for the RA-Guard > device to reassemble the fragments and so to be able to check whether > this a RA message or not? It's possible, perhaps. But the trade-off is to much IMHO. = Forcing a L2 device to inspect every packet and re-asemble them is = unfeasible or too expensive (similar for a more intelligent device = listening for every packet in the network looking for rogue RAs). The = same for extension headers in NDP, we are not using it today, may be we = will, but the trade-off to have it "just in case" is too much. >=20 > Thanks in advance for your reply. >=20 > Best regards. >=20 > JMC. Cheers, .as >=20 >=20 > 2011/6/10 Fernando Gont : >> Hi, >>=20 >> Some folks have expressed (both on-list and off-list) that they would >> prefer a less agressive solution for the RA-Guard evasion = vulnerability. >> So I'd like to hear comments about the possible alternatives.. >>=20 >> The current I-Ds (draft-gont-6man-nd-extension-headers and >> draft-gont-v6ops-ra-guard-evasion) basically take this approach: >>=20 >> * Prohibit use of extension headers in ND messages. A host >> implementation must not produce these packets, and must discard them = if >> it receives them >> * This results in a RA-Guard implementation that is as simple as >> possible (it only has to look at the header following the fixed IPv6 >> header). >>=20 >>=20 >> A more relaxed approach would be as follows: >> * Extension headers are allowed with ND messages. >> * If the packet is fragmented, the upper-layer header (ICMPv6 in this >> case) must be present in the first fragment (i.e., hosts must not >> generate packets that violate this requirement, and must discard them = if >> they receive them). >> * Possibly have the RA-Guard box enforce a limit on the maximum = number >> of extension headers that it will process (e.g., if after jumping to >> the, say 10th header the upper-layer header is not found, drop the = packet) >> * This approach is less aggressive than the one proposed in the >> aforementioned I-Ds (i.e., more flexibility), but of course would = also >> mean that the RA-Guard implementation would need to follow the header >> chain, thus leading to increased complexity, and possible performance >> issues. >>=20 >> Any comments/thoughts will be very much appreciated. >>=20 >> Thanks! >>=20 >> 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 >>=20 >>=20 >>=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 From jeanmichel.combes@gmail.com Thu Jun 16 13:44:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B01611E82F1; Thu, 16 Jun 2011 13:44:52 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7AVAnZ9YRmR; Thu, 16 Jun 2011 13:44:51 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF0111E82D6; Thu, 16 Jun 2011 13:44:51 -0700 (PDT) Received: by gyf3 with SMTP id 3so782950gyf.31 for ; Thu, 16 Jun 2011 13:44:50 -0700 (PDT) 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=bHHAsTDoB9FhUgwdJFv1uk7yDZ662wCaG0y5sdg2wZ8=; b=UWMXnpCsCCsXquNwAFrlhErzQaFwWVrCGSFAAIGKY3q+oPAADHTjbbGrmmYKxOcWER e3HNvjh7B9H/G4hZZwSYBC3pPBtptulFGL6y7ojvGw6kfnB7ig1yRVuuuJZA46viQUGJ YfVMF8fr9y8RcKsN4A+pUhS/tw4eaLEgzQq1o= 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=cyLOFHKUV9E+yLE6TQ0oIPaqIbiWKVJPxXzTALmxc1EPP4zR91lRulRYfi7gvOl2EN xWE6fdGTZDB7M65J0zGTk++v6RqS0nN+8XrRaFgL+5Iilp38en6HEA7yWE44jgAElTNb ycFJa2KsQyk3Xz992dMBYN8U2Askm5FsG2jZQ= MIME-Version: 1.0 Received: by 10.236.77.165 with SMTP id d25mr2001300yhe.25.1308257090865; Thu, 16 Jun 2011 13:44:50 -0700 (PDT) Received: by 10.147.83.20 with HTTP; Thu, 16 Jun 2011 13:44:50 -0700 (PDT) In-Reply-To: <351EBA42-0077-4AAD-8D4C-D2880B81FBC6@gmail.com> References: <4DF291D0.7080707@gont.com.ar> <351EBA42-0077-4AAD-8D4C-D2880B81FBC6@gmail.com> Date: Thu, 16 Jun 2011 22:44:50 +0200 Message-ID: From: Jean-Michel Combes To: Arturo Servin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 20:44:52 -0000 Hi Arturo, at first, thanks for your reply. 2011/6/16 Arturo Servin : > Jean-Michel, > > On 16 Jun 2011, at 14:13, Jean-Michel Combes wrote: > [snip] >> >> o draft-gont-6man-nd-extension-headers >> >> IMHO, this is not a good idea to forbid the use of IPv6 extension with >> NDP messages, especially when the reason is partially based on >> implementation issues (i.e. the implementation is not able to process >> an IPv6 packet): today, there is no real use of Extension header with >> NDP but, tomorrow, if we need such an use for a solution, what will >> happen? > > =A0 =A0 =A0 =A0See below > >> Regarding the fragmentation, is it not possible for the RA-Guard >> device to reassemble the fragments and so to be able to check whether >> this a RA message or not? > > =A0 =A0 =A0 =A0It's possible, perhaps. But the trade-off is to much IMHO.= Forcing a L2 device to inspect every packet and re-asemble them is unfeasi= ble or too expensive (similar for a more intelligent device listening for e= very packet in the network looking for rogue RAs). The same for extension h= eaders in NDP, we are not using it today, may be we will, but the trade-off= to have it "just in case" is too much. > Why is this unfeasible? Again an implementation issue? Why is it too expensive? Memory issue? CPU issue? Something else? Best regards. JMC. From joelja@bogus.com Thu Jun 16 13:57:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC9011E829D; Thu, 16 Jun 2011 13:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tvhDzDIwnUA; Thu, 16 Jun 2011 13:57:49 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4603C11E8268; Thu, 16 Jun 2011 13:57:49 -0700 (PDT) Received: from zorch.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p5GKvhKp080661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 16 Jun 2011 20:57:44 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Thu, 16 Jun 2011 13:57:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6CDF3074-DB43-443C-BDE3-82558E4F844E@bogus.com> References: <4DF291D0.7080707@gont.com.ar> <351EBA42-0077-4AAD-8D4C-D2880B81FBC6@gmail.com> To: Jean-Michel Combes X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 16 Jun 2011 20:57:44 +0000 (UTC) Cc: "ipv6@ietf.org" , IPv6 Operations , Arturo Servin Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 20:57:50 -0000 On Jun 16, 2011, at 1:44 PM, Jean-Michel Combes wrote: > Hi Arturo, >=20 > at first, thanks for your reply. >=20 > 2011/6/16 Arturo Servin : >> Jean-Michel, >>=20 >> On 16 Jun 2011, at 14:13, Jean-Michel Combes wrote: >>=20 >=20 > [snip] >=20 >>>=20 >>> o draft-gont-6man-nd-extension-headers >>>=20 >>> IMHO, this is not a good idea to forbid the use of IPv6 extension = with >>> NDP messages, especially when the reason is partially based on >>> implementation issues (i.e. the implementation is not able to = process >>> an IPv6 packet): today, there is no real use of Extension header = with >>> NDP but, tomorrow, if we need such an use for a solution, what will >>> happen? >>=20 >> See below >>=20 >>> Regarding the fragmentation, is it not possible for the RA-Guard >>> device to reassemble the fragments and so to be able to check = whether >>> this a RA message or not? >>=20 >> It's possible, perhaps. But the trade-off is to much IMHO. = Forcing a L2 device to inspect every packet and re-asemble them is = unfeasible or too expensive (similar for a more intelligent device = listening for every packet in the network looking for rogue RAs). The = same for extension headers in NDP, we are not using it today, may be we = will, but the trade-off to have it "just in case" is too much. >>=20 >=20 > Why is this unfeasible? Again an implementation issue? > Why is it too expensive? Memory issue? CPU issue? Something else? it's expensive because you have to set them aside and re-assemble and nd = is going to be reassembled in a control-plane processor, which leads to = cases where the attacker deliberately maximizes the expense associated = with doing so.=20 > Best regards. >=20 > JMC. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From joelja@bogus.com Fri Jun 17 12:50:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D2C9E8042 for ; Fri, 17 Jun 2011 12:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.178 X-Spam-Level: X-Spam-Status: No, score=-102.178 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eymec96hgnOL for ; Fri, 17 Jun 2011 12:50:02 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4765C9E800A for ; Fri, 17 Jun 2011 12:50:01 -0700 (PDT) Received: from zorch.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p5HJntYZ006499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 17 Jun 2011 19:49:57 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-18--679492667 From: Joel Jaeggli In-Reply-To: Date: Fri, 17 Jun 2011 12:49:48 -0700 Message-Id: <31BCF9EC-7A49-4C5B-B62A-CAECF66F23F1@bogus.com> References: To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 17 Jun 2011 19:49:58 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 19:50:03 -0000 --Apple-Mail-18--679492667 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 3, 2011, at 8:13 AM, Templin, Fred L wrote: > Hello, >=20 > Significant improvements have been made to this document > (below) based on comments received and new observations. > IMHO, this is an important document for enabling transition > to IPv6 within IPv4 sites; hence, I would like to call for > working group adoption at this time. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 Replying to this message as a way to maintain the threading. these notes = are relative to the current version of the draft which I reviewed last = week: http://tools.ietf.org/html/draft-templin-v6ops-isops-10 So I tried for a while to separate the operational advice that could be = applied to my 2005 era knowledge of isatap and there's quite a few = things that jive with that (tunnel loops for example).=20 In other cases such isatap dhcpv6 (4.5) I'm a bit-off in the weeds, what = implementations are capable of doing that? Are we recommending that they = do it? do they already? Regarding aero (section 4.6) that looks pretty much like new work or an = extension to the specification. Are there participants with extant isatap deployements or host = implementations or knowledge fresher than mine that would care to = comment on this draft. section 9 alternative approaches, there's some consensus that rfc 3056 = was never really deployed so the reference to 6to4 should probably be to = 3068. --Apple-Mail-18--679492667 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hello,

Significant improvements have been made = to this document
(below) based on comments received and new = observations.
IMHO, this is an important document for enabling = transition
to IPv6 within IPv4 sites; hence, I would like to call = for
working group adoption at this time.

Thanks - Fred
fred.l.templin@boeing.com

Replying to this message as a way to = maintain the threading. these notes are relative to the current version = of the draft which I reviewed last week:


So = I tried for a while to separate the operational advice that could be = applied to my 2005 era knowledge of isatap and there's  quite a few = things that jive with that (tunnel loops for = example). 

In other = cases such isatap dhcpv6 (4.5) I'm a bit-off in the weeds, what = implementations are capable of doing that? Are we recommending that they = do it? do they already?

Regarding = aero (section 4.6) that looks pretty much like new work or an extension = to the specification.

Are there = participants with extant isatap deployements or host implementations or = knowledge fresher than mine that would care to comment on this = draft.

section 9 = alternative approaches, there's some consensus that rfc 3056 was never = really deployed so the reference to 6to4 should probably be to = 3068.

= --Apple-Mail-18--679492667-- From joelja@bogus.com Fri Jun 17 13:39:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8899E8033 for ; Fri, 17 Jun 2011 13:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cte98u16Yfue for ; Fri, 17 Jun 2011 13:39:51 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 161969E802B for ; Fri, 17 Jun 2011 13:39:50 -0700 (PDT) Received: from zorch.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p5HKd7JS007547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 17 Jun 2011 20:39:11 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <009a01cc298f$cd75bfd0$68613f70$@com> Date: Fri, 17 Jun 2011 13:39:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3D7ADBC4-ED1B-4E06-8655-0C54EEB8839D@bogus.com> References: <009a01cc298f$cd75bfd0$68613f70$@com> To: Tina Tsou X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 17 Jun 2011 20:39:12 +0000 (UTC) Cc: Dan Romascanu , "v6ops@ietf.org Operations" Subject: Re: [v6ops] Request for Operations Directorate Review of draft-iesg-rfc1150bis-01 by 2011-07-08 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 20:39:53 -0000 It was requested that I review rfc1150bis-01 for operational = considerations.=20 I believe that the conclusion of the FYI document series has no = implications for operations generally. In the context of IETF OPS area procedures, a future document = superseding an existing FYI document example rfc 2901 might be = identified as a BCP or variously by it's other standards or = non-standards (informational) track status. joel On Jun 12, 2011, at 11:04 PM, Tina Tsou wrote: > Hello, > As a member of the Operations Directorate you are being asked to = review > the following draft which is in IETF last call for it's operational > impact. >=20 > IETF Last Call: > The file can be obtained via > http://datatracker.ietf.org/doc/draft-iesg-rfc1150bis/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-iesg-rfc1150bis/ >=20 > Please provide comments and review to the Ops-dir mailing list > (ops-dir@ietf.org) by 2011-07-08, and include the authors of the > draft as well. >=20 > A Check-list of possible questions/topics to address in an OPS-DIR=20 > review may be found in Appendix A of RFC 5706. > Only include the questions that apply to your review. >=20 > Would you add the review requests and update the status yourself at = our wiki > page? > http://trac.tools.ietf.org/area/ops/trac/wiki/Directorates >=20 >=20 > Thank you, > Tina > http://tinatsou.weebly.com >=20 >=20 From dwing@cisco.com Fri Jun 17 17:25:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C96E11E8118 for ; Fri, 17 Jun 2011 17:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uvhwpb2-XWuS for ; Fri, 17 Jun 2011 17:25:51 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 809E211E80EE for ; Fri, 17 Jun 2011 17:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2101; q=dns/txt; s=iport; t=1308356751; x=1309566351; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=Uq5djrE5g09k9ukEMHtcPEqbMlEwj/Z0yeq8NUSRr+U=; b=PdCEBVd1MpIP+JX5gZBD8cXLcuBYU+HKswVucvj5P6Dull1fgiAwH4EA cdVyNiXOadIj1pikPm+gfTRqjwH9vDRMK4CKNwTWAx1PG8HE5aVdzm9uj atmiPcK7Z6nxEfiJdqkGfs9sAE6F8xOL4gT9BDMZoFifwTPT/Uegda04v 0=; X-IronPort-AV: E=Sophos;i="4.65,384,1304294400"; d="scan'208";a="379559845" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 18 Jun 2011 00:25:51 +0000 Received: from dwingWS (dhcp-128-107-104-194.cisco.com [128.107.104.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5I0Ppvu002422; Sat, 18 Jun 2011 00:25:51 GMT From: "Dan Wing" To: Date: Fri, 17 Jun 2011 17:25:51 -0700 Message-ID: <007101cc2d4e$473e8380$d5bb8a80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwtTkceUOlQkVa2S6yr1ZMfIlYYeA== Content-Language: en-us Subject: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 00:25:52 -0000 Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the feedback we have received is along the lines of: * simplify further * don't worry about sending excessive packets * prefer IPv6, unless it's failing "a lot" To that end, there seem to be three approaches. We would like feedback on which direction to document: After calling getaddrinfo(), v6ops needs to decide if we should: a. initiate two simultaneous connection attempts (first IPv6 address and first IPv4 address). Both connections can be used by HTTP. Subsequent connections to that same hostname would use whichever address family connected quicker. b. initiate one connection attempt to the first address returned. If it isn't successful after NNN milliseconds, initiate a connection attempt to the first IPv4 address returned by getaddrinfo(). (This is what Chrome is doing.) c. initiate one connection attempt to the first address returned. If it isn't successful after NNN milliseconds, initiate a connection attempt to the next address returned by getaddrinfo(). To deal with cases where "IPv6 is failing a lot", we might consider ways to pick a good initial "NNN" value. For example, we might use a default of 200-300ms, and also define a DHCPv6 option so the network could convey a different default. This seems useful for all sorts of situations, most notably 3G wireless (which wouldn't use DHCPv6, but could use the same idea to provide the same sort of information in IPCP or whatever it likes.) We might also consider ways to automatically tune NNN up or down. For example, if IPv6 connected successfully, we can increase NNN. If an IPv6 connection times out and IPv4 wins, we decrease NNN. This is similar to what we are doing today in Happy Eyeballs -00, -01, and -02. But we would simplify this from what is described in Happy Eyeballs today (which has a Tolerance Interval and suchlike, based on previous feedback). Any thoughts on the various ideas above? -d From Ted.Lemon@nominum.com Fri Jun 17 19:32:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7002F11E81C7 for ; Fri, 17 Jun 2011 19:32:29 -0700 (PDT) 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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zb1a8otXpGGa for ; Fri, 17 Jun 2011 19:32:28 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 604D311E80F8 for ; Fri, 17 Jun 2011 19:32:27 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTfwOOgw9YwjwFNR7fB6t43mcDCP9Z+Vb@postini.com; Fri, 17 Jun 2011 19:32:28 PDT 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 8A48AF8005 for ; Fri, 17 Jun 2011 19:32:26 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7AC51190064; Fri, 17 Jun 2011 19:32:26 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([169.254.1.65]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0289.001; Fri, 17 Jun 2011 19:32:26 -0700 From: Ted Lemon To: Dan Wing Thread-Topic: [v6ops] simplfying Happy Eyeballs further Thread-Index: AcwtTkceUOlQkVa2S6yr1ZMfIlYYeAAEa7oV Date: Sat, 18 Jun 2011 02:32:25 +0000 Message-ID: References: <007101cc2d4e$473e8380$d5bb8a80$@com> In-Reply-To: <007101cc2d4e$473e8380$d5bb8a80$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_B4DE573BC88A48DEB809D770D639C3DEnominumcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 02:32:29 -0000 --_000_B4DE573BC88A48DEB809D770D639C3DEnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think what you've proposed would work nicely. --_000_B4DE573BC88A48DEB809D770D639C3DEnominumcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


I think what you've proposed would work nicely.  --_000_B4DE573BC88A48DEB809D770D639C3DEnominumcom_-- From ipng@69706e6720323030352d30312d31340a.nosense.org Fri Jun 17 20:23:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307799E8017 for ; Fri, 17 Jun 2011 20:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=-0.300, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh-2GgSaAWCv for ; Fri, 17 Jun 2011 20:23:48 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 433069E8011 for ; Fri, 17 Jun 2011 20:23:48 -0700 (PDT) Received: from 114-30-99-224.ip.adam.com.au ([114.30.99.224] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QXm8O-0005Nw-83; Sat, 18 Jun 2011 12:53:44 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 971D53B33E; Sat, 18 Jun 2011 12:53:43 +0930 (CST) Date: Sat, 18 Jun 2011 12:53:43 +0930 From: Mark Smith To: "Dan Wing" Message-ID: <20110618125343.059593a2@opy.nosense.org> In-Reply-To: <007101cc2d4e$473e8380$d5bb8a80$@com> References: <007101cc2d4e$473e8380$d5bb8a80$@com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 03:23:50 -0000 Hi Dan, On Fri, 17 Jun 2011 17:25:51 -0700 "Dan Wing" wrote: > Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the > feedback we have received is along the lines of: > > * simplify further > * don't worry about sending excessive packets > * prefer IPv6, unless it's failing "a lot" > > To that end, there seem to be three approaches. We would like > feedback on which direction to document: > > After calling getaddrinfo(), v6ops needs to decide if we should: > a. initiate two simultaneous connection attempts (first IPv6 > address and first IPv4 address). Both connections can be used > by HTTP. Subsequent connections to that same hostname would > use whichever address family connected quicker. I like this first option as it is using actual connection response times as the metric for selection, rather than DNS response times. I don't think a slow DNS response should prevent a fast IPv6 or IPv4 server being used. How often would this selection be reset? Perhaps the same or similar interval as PMTUD? I'd also be curious what methods/mechanisms are used when there are multiple IPv4 and/or IPv6 addresses supplied if the first connection attempts fail. The goal of happy eyeballs would suggest trying to connect to all addresses at once for the best chance of connection success, but that probably would create too many connection setups. Or maybe not - if somebody has put multiple addresses in DNS, then high availability is a likely goal of theirs, so it might not be unreasonable for clients to do everything they can to achieve that goal too. > b. initiate one connection attempt to the first address returned. > If it isn't successful after NNN milliseconds, initiate a > connection attempt to the first IPv4 address returned by > getaddrinfo(). (This is what Chrome is doing.) > c. initiate one connection attempt to the first address returned. > If it isn't successful after NNN milliseconds, initiate a > connection attempt to the next address returned by > getaddrinfo(). > > To deal with cases where "IPv6 is failing a lot", we might consider > ways to pick a good initial "NNN" value. For example, we might > use a default of 200-300ms, and also define a DHCPv6 option so > the network could convey a different default. This seems > useful for all sorts of situations, most notably 3G wireless > (which wouldn't use DHCPv6, but could use the same idea to > provide the same sort of information in IPCP or whatever it > likes.) > > We might also consider ways to automatically tune NNN up or > down. For example, if IPv6 connected successfully, we can > increase NNN. If an IPv6 connection times out and IPv4 wins, > we decrease NNN. This is similar to what we are doing today > in Happy Eyeballs -00, -01, and -02. But we would simplify > this from what is described in Happy Eyeballs today (which > has a Tolerance Interval and suchlike, based on previous > feedback). > > > Any thoughts on the various ideas above? > > -d > Regards, Mark. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Ted.Lemon@nominum.com Fri Jun 17 22:10:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BC811E80DC for ; Fri, 17 Jun 2011 22:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ex5zQM6uNrHe for ; Fri, 17 Jun 2011 22:10:24 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id E934811E8080 for ; Fri, 17 Jun 2011 22:10:22 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTfwzPhfLmGy7tmerfbclhqBn5dmcgFj4@postini.com; Fri, 17 Jun 2011 22:10:23 PDT 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 DBF181B8577 for ; Fri, 17 Jun 2011 22:10:21 -0700 (PDT) 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 ESMTPS id C9F78190064; Fri, 17 Jun 2011 22:10:21 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.1.10] (24.42.78.9) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 17 Jun 2011 22:10:21 -0700 MIME-Version: 1.0 (Apple Message framework v1237.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_2F71E317-BA88-4F28-A93A-FCB82E94EA21" From: Ted Lemon In-Reply-To: Date: Sat, 18 Jun 2011 01:10:19 -0400 Message-ID: <881B0821-5492-42B2-BC41-C9ECCCC5580B@nominum.com> References: <007101cc2d4e$473e8380$d5bb8a80$@com> To: Dan Wing X-Mailer: Apple Mail (2.1237.1) Cc: IPv6 Operations Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 05:10:27 -0000 --Apple-Mail=_2F71E317-BA88-4F28-A93A-FCB82E94EA21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Jun 17, 2011, at 10:32 PM, Ted Lemon wrote: > I think what you've proposed would work nicely.=20 Oh, the irony. I read what you'd written as if it were a single = proposal, rather than three alternatives, and somehow it made sense that = way to me. I will have to reread the proposal... Sorry for the bizarre = Emily Latella comment. --Apple-Mail=_2F71E317-BA88-4F28-A93A-FCB82E94EA21 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" I think what = you've proposed would work = nicely. 

Oh, the irony.   I = read what you'd written as if it were a single proposal, rather than = three alternatives, and somehow it made sense that way to me.   I = will have to reread the proposal... Sorry for the bizarre Emily Latella = comment.

= --Apple-Mail=_2F71E317-BA88-4F28-A93A-FCB82E94EA21-- From marka@isc.org Sat Jun 18 02:19:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF82C11E813E for ; Sat, 18 Jun 2011 02:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8pb0bgPjy9l for ; Sat, 18 Jun 2011 02:19:39 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 18BB211E8135 for ; Sat, 18 Jun 2011 02:19:38 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 1A21F5F993F; Sat, 18 Jun 2011 09:19:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id A4533216C7B; Sat, 18 Jun 2011 09:19:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 37EA010E5EB2; Sat, 18 Jun 2011 19:19:06 +1000 (EST) To: "Dan Wing" From: Mark Andrews References: <007101cc2d4e$473e8380$d5bb8a80$@com> In-reply-to: Your message of "Fri, 17 Jun 2011 17:25:51 MST." <007101cc2d4e$473e8380$d5bb8a80$@com> Date: Sat, 18 Jun 2011 19:19:06 +1000 Message-Id: <20110618091906.37EA010E5EB2@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 09:19:39 -0000 In message <007101cc2d4e$473e8380$d5bb8a80$@com>, "Dan Wing" writes: > Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the > feedback we have received is along the lines of: > > * simplify further > * don't worry about sending excessive packets > * prefer IPv6, unless it's failing "a lot" > > To that end, there seem to be three approaches. We would like > feedback on which direction to document: > > After calling getaddrinfo(), v6ops needs to decide if we should: > a. initiate two simultaneous connection attempts (first IPv6 > address and first IPv4 address). Both connections can be used > by HTTP. Subsequent connections to that same hostname would > use whichever address family connected quicker. > b. initiate one connection attempt to the first address returned. > If it isn't successful after NNN milliseconds, initiate a > connection attempt to the first IPv4 address returned by > getaddrinfo(). (This is what Chrome is doing.) > c. initiate one connection attempt to the first address returned. > If it isn't successful after NNN milliseconds, initiate a > connection attempt to the next address returned by > getaddrinfo(). c. Is what I implemented with decreasing NNN on subsequent connection attempts. 100 to 200ms make for a good initial NNN. > To deal with cases where "IPv6 is failing a lot", we might consider > ways to pick a good initial "NNN" value. For example, we might > use a default of 200-300ms, and also define a DHCPv6 option so > the network could convey a different default. This seems > useful for all sorts of situations, most notably 3G wireless > (which wouldn't use DHCPv6, but could use the same idea to > provide the same sort of information in IPCP or whatever it > likes.) > > We might also consider ways to automatically tune NNN up or > down. For example, if IPv6 connected successfully, we can > increase NNN. If an IPv6 connection times out and IPv4 wins, > we decrease NNN. This is similar to what we are doing today > in Happy Eyeballs -00, -01, and -02. But we would simplify > this from what is described in Happy Eyeballs today (which > has a Tolerance Interval and suchlike, based on previous > feedback). > > > Any thoughts on the various ideas above? > > -d > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From pch-b2B3A6689@u-1.phicoh.com Sat Jun 18 03:04:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD5511E8157 for ; Sat, 18 Jun 2011 03:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.149 X-Spam-Level: X-Spam-Status: No, score=-8.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvnGNyYJM2A0 for ; Sat, 18 Jun 2011 03:04:34 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id D149C11E808D for ; Sat, 18 Jun 2011 03:04:32 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QXsO8-0001gMC; Sat, 18 Jun 2011 12:04:24 +0200 Message-Id: To: "Dan Wing" From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Fri, 17 Jun 2011 17:25:51 -0700 ." <007101cc2d4e$473e8380$d5bb8a80$@com> Date: Sat, 18 Jun 2011 12:04:18 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 10:04:35 -0000 In your letter dated Fri, 17 Jun 2011 17:25:51 -0700 you wrote: >Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the >feedback we have received is along the lines of: > > * simplify further > * don't worry about sending excessive packets > * prefer IPv6, unless it's failing "a lot" > >To that end, there seem to be three approaches. We would like >feedback on which direction to document: > >After calling getaddrinfo(), v6ops needs to decide if we should: > a. initiate two simultaneous connection attempts (first IPv6 > address and first IPv4 address). Both connections can be used > by HTTP. Subsequent connections to that same hostname would > use whichever address family connected quicker. > b. initiate one connection attempt to the first address returned. > If it isn't successful after NNN milliseconds, initiate a > connection attempt to the first IPv4 address returned by > getaddrinfo(). (This is what Chrome is doing.) > c. initiate one connection attempt to the first address returned. > If it isn't successful after NNN milliseconds, initiate a > connection attempt to the next address returned by > getaddrinfo(). I like what Chrome is doing because it is so simple. However, I'm a bit worried that it may be too simple and that when it's deployed on a large scale we wish we would have gone for something a bit more complex. The other end of the scale is to have a system that keeps track of the performance of both IPv4 and IPv6 and uses that to set preferences and timeouts dynamically. In the long run I prefer to have something like that. >To deal with cases where "IPv6 is failing a lot", we might consider >ways to pick a good initial "NNN" value. For example, we might >use a default of 200-300ms, and also define a DHCPv6 option so >the network could convey a different default. This seems >useful for all sorts of situations, most notably 3G wireless >(which wouldn't use DHCPv6, but could use the same idea to >provide the same sort of information in IPCP or whatever it >likes.) To me this sounds overly complex. A host is quite capable of computing that value on its own. >Any thoughts on the various ideas above? I think that the main thing we should do is to figure out what any Happy Eyeballs implementation should *not* do. Because, it will cause too much load on the network or it will not result in the right user experience. After that, any algorithms that we may come up with are just friendly advice to implementors. (Now that I'm playing a bit with my own HE implementation, I've become quite enthusiastic about its potential. I never liked the destination selection policies. I much prefer systems to configure themselves) From ek@google.com Sat Jun 18 06:47:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7E311E8074 for ; Sat, 18 Jun 2011 06:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGmPXktTv6xY for ; Sat, 18 Jun 2011 06:47:05 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7683F11E8073 for ; Sat, 18 Jun 2011 06:47:05 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p5IDl2bG014266 for ; Sat, 18 Jun 2011 06:47:03 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308404824; bh=rTTflqCJrsLE7p1ROT1iy549sjc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=hVORWDrz57XY2wrX0FSuuzEze9NLVAk6uPH2xf+LWr0By/k81YwTpic98kCTwtfP2 tZwrp74OoxboXifSphfdQ== Received: from pzk30 (pzk30.prod.google.com [10.243.19.158]) by hpaq11.eem.corp.google.com with ESMTP id p5IDkXmB003135 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 18 Jun 2011 06:47:01 -0700 Received: by pzk30 with SMTP id 30so3476914pzk.18 for ; Sat, 18 Jun 2011 06:47:01 -0700 (PDT) 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=Pazqh3BbS2O5TzovPTS0K/I+2jKFMzCrYU4yBvUUQCo=; b=DY6lAQGV8dOwsuJcjHu4Tq1nr6q4vsBc+XSd1kjAvQaWU1FS/ND44G/A+WtR7fvHZC ts2X3YZdrN50QgH/ttiw== 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=YCKeeKzUNEfGsIMDxuk85N2bBrcySk5ZSZ5qQZr2CNNXU6utl7bMH1LL/SV+rTgJKC ouWGSxi4xP8rH/vYUIQg== MIME-Version: 1.0 Received: by 10.142.242.6 with SMTP id p6mr549819wfh.96.1308404820975; Sat, 18 Jun 2011 06:47:00 -0700 (PDT) Received: by 10.142.179.17 with HTTP; Sat, 18 Jun 2011 06:47:00 -0700 (PDT) In-Reply-To: References: <007101cc2d4e$473e8380$d5bb8a80$@com> Date: Sat, 18 Jun 2011 06:47:00 -0700 Message-ID: From: Erik Kline To: Philip Homburg Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 13:47:06 -0000 > (Now that I'm playing a bit with my own HE implementation, I've become quite > enthusiastic about its potential. I never liked the destination selection > policies. I much prefer systems to configure themselves) Agreed that recommending connection performance techniques has the potential to be much simpler and I think, more importantly, more /future proof/ than things like destination selection have shown to be, given how difficult it can be upgrade systems in the field. From brian.e.carpenter@gmail.com Sat Jun 18 06:53:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B42D11E8097 for ; Sat, 18 Jun 2011 06:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.153 X-Spam-Level: X-Spam-Status: No, score=-103.153 tagged_above=-999 required=5 tests=[AWL=-0.154, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btM-+6BQiHGy for ; Sat, 18 Jun 2011 06:53:53 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF7211E8073 for ; Sat, 18 Jun 2011 06:53:53 -0700 (PDT) Received: by fxm15 with SMTP id 15so370112fxm.31 for ; Sat, 18 Jun 2011 06:53:52 -0700 (PDT) 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=idTQRTO+SUYoDFHq2VZat7Fi1k4Zk3dtN36mwwnoHNo=; b=RY2egDDjIuMpvXF8OixwlEv3zvvWZFZG1YPFYsC/Px3ZyF56YxRCQM862G1QRtwSgx pq84OWe7aTJGpPZIYYPs4O0VObtyrp0ASeGJjZJwf0jomLTqCTFrhS8WHTAQLaUr29GX RznnC6H+81qgiuj+2f3CN9tWud/Fvi8a6DP2s= 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=u/e1dt/AoRQjosvR1gkg8LHjEvP8T+sY3P102wI/QtlrcwZMi3FpBUtSpzCOCJ21r2 dzt+tXNmelbaRPFE5Tt6FezFNqDAxpWS1gxXb9K9VeUEfllFeFf3A3EjuZ7qJKfNwJUY gn2oduM+7XRbe8nXKTgU+pmFzSOfGJIa2nnaU= Received: by 10.223.2.205 with SMTP id 13mr3673173fak.138.1308405232414; Sat, 18 Jun 2011 06:53:52 -0700 (PDT) Received: from [10.255.25.96] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id g8sm1824087fai.44.2011.06.18.06.53.49 (version=SSLv3 cipher=OTHER); Sat, 18 Jun 2011 06:53:51 -0700 (PDT) Message-ID: <4DFCADEA.4080100@gmail.com> Date: Sun, 19 Jun 2011 01:53:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing References: <007101cc2d4e$473e8380$d5bb8a80$@com> In-Reply-To: <007101cc2d4e$473e8380$d5bb8a80$@com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 13:53:54 -0000 I prefer > a. initiate two simultaneous connection attempts or even three. Some studies we've done on SHIM6/REAP and MPTCP performance suggest that probing up to 3 addresses in parallel doesn't create a significant load but does improve the time to establish a connection. Regards Brian On 2011-06-18 12:25, Dan Wing wrote: > Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the > feedback we have received is along the lines of: > > * simplify further > * don't worry about sending excessive packets > * prefer IPv6, unless it's failing "a lot" > > To that end, there seem to be three approaches. We would like > feedback on which direction to document: > > After calling getaddrinfo(), v6ops needs to decide if we should: > a. initiate two simultaneous connection attempts (first IPv6 > address and first IPv4 address). Both connections can be used > by HTTP. Subsequent connections to that same hostname would > use whichever address family connected quicker. > b. initiate one connection attempt to the first address returned. > If it isn't successful after NNN milliseconds, initiate a > connection attempt to the first IPv4 address returned by > getaddrinfo(). (This is what Chrome is doing.) > c. initiate one connection attempt to the first address returned. > If it isn't successful after NNN milliseconds, initiate a > connection attempt to the next address returned by > getaddrinfo(). > > To deal with cases where "IPv6 is failing a lot", we might consider > ways to pick a good initial "NNN" value. For example, we might > use a default of 200-300ms, and also define a DHCPv6 option so > the network could convey a different default. This seems > useful for all sorts of situations, most notably 3G wireless > (which wouldn't use DHCPv6, but could use the same idea to > provide the same sort of information in IPCP or whatever it > likes.) > > We might also consider ways to automatically tune NNN up or > down. For example, if IPv6 connected successfully, we can > increase NNN. If an IPv6 connection times out and IPv4 wins, > we decrease NNN. This is similar to what we are doing today > in Happy Eyeballs -00, -01, and -02. But we would simplify > this from what is described in Happy Eyeballs today (which > has a Tolerance Interval and suchlike, based on previous > feedback). > > > Any thoughts on the various ideas above? > > -d > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From cb.list6@gmail.com Sat Jun 18 07:46:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50DC11E80D5 for ; Sat, 18 Jun 2011 07:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeGmrjZnT5gg for ; Sat, 18 Jun 2011 07:46:56 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C586F11E8070 for ; Sat, 18 Jun 2011 07:46:55 -0700 (PDT) Received: by wwe5 with SMTP id 5so840190wwe.13 for ; Sat, 18 Jun 2011 07:46:54 -0700 (PDT) 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=IM2QAx6ZY51zpd/2uOMdgLgtnH3ZXo8fqHjdq0/XKZs=; b=pQ4Vvg2Pzu9Wt2fi1eWlRzMn48V5GDPjfvOpTN7uTKddCl26KeWPzxMT7NRFB0VnNJ EaEhDY9HvhsdvJXUFv9fQonqKzPAacZTIoVNiD5ArpvBb0xQFLasXT7ZMpeRYZyGH2bp BWt5xyoWsJe94kmbhS0IPEC0PQXv8HWc3ynZg= 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=l8zPf8sM2fJuCgujW4YUKZXIr/jd+JwlCmPZgWPDDzcPAYyAHrIQEK0kMF7yVbumn+ j4OJhUzd5fdwnEkgs/zlXS64leQx5MPfh1S7U332Rmcc2r42n7RtOJEUXEglhTSi8G4G FYzLSHbj5pHMm2jIV0yN4M9bcl3h1Wi4E8Uos= MIME-Version: 1.0 Received: by 10.216.59.81 with SMTP id r59mr3207173wec.40.1308408414735; Sat, 18 Jun 2011 07:46:54 -0700 (PDT) Received: by 10.216.165.82 with HTTP; Sat, 18 Jun 2011 07:46:54 -0700 (PDT) Received: by 10.216.165.82 with HTTP; Sat, 18 Jun 2011 07:46:54 -0700 (PDT) In-Reply-To: <4DFCADEA.4080100@gmail.com> References: <007101cc2d4e$473e8380$d5bb8a80$@com> <4DFCADEA.4080100@gmail.com> Date: Sat, 18 Jun 2011 07:46:54 -0700 Message-ID: From: Cameron Byrne To: Brian E Carpenter Content-Type: multipart/alternative; boundary=000e0cdff822c80ea204a5fd92ae Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 14:46:57 -0000 --000e0cdff822c80ea204a5fd92ae Content-Type: text/plain; charset=ISO-8859-1 On Jun 18, 2011 6:54 AM, "Brian E Carpenter" wrote: > > I prefer > > > a. initiate two simultaneous connection attempts > > or even three. Some studies we've done on SHIM6/REAP and MPTCP performance > suggest that probing up to 3 addresses in parallel doesn't create > a significant load but does improve the time to establish a connection. > Just like cell phones that constantly turn off and on their data connections to optimize battery life, but in turn wreck the network with a flood of signalling to attach and detach. Please no. Some of us are thinking about cgn exit strategies, and these ipv4 connections will be enough noise that I cannot properly dimension the ramp down. Sorry, we cannot always engineer the system to optimize on just the user experience and expect all the other elements to scale and perform well. I know there may be some backoff mechanism and affinity, but this is a slippery slope where implementers will look to "improve " on a good idea to make their product look better. I do not look forward to my HE refrigerator sending out simultaneous connections to upload my grocery list to the cloud. Cb > Regards > Brian > > On 2011-06-18 12:25, Dan Wing wrote: > > Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the > > feedback we have received is along the lines of: > > > > * simplify further > > * don't worry about sending excessive packets > > * prefer IPv6, unless it's failing "a lot" > > > > To that end, there seem to be three approaches. We would like > > feedback on which direction to document: > > > > After calling getaddrinfo(), v6ops needs to decide if we should: > > a. initiate two simultaneous connection attempts (first IPv6 > > address and first IPv4 address). Both connections can be used > > by HTTP. Subsequent connections to that same hostname would > > use whichever address family connected quicker. > > b. initiate one connection attempt to the first address returned. > > If it isn't successful after NNN milliseconds, initiate a > > connection attempt to the first IPv4 address returned by > > getaddrinfo(). (This is what Chrome is doing.) > > c. initiate one connection attempt to the first address returned. > > If it isn't successful after NNN milliseconds, initiate a > > connection attempt to the next address returned by > > getaddrinfo(). > > > > To deal with cases where "IPv6 is failing a lot", we might consider > > ways to pick a good initial "NNN" value. For example, we might > > use a default of 200-300ms, and also define a DHCPv6 option so > > the network could convey a different default. This seems > > useful for all sorts of situations, most notably 3G wireless > > (which wouldn't use DHCPv6, but could use the same idea to > > provide the same sort of information in IPCP or whatever it > > likes.) > > > > We might also consider ways to automatically tune NNN up or > > down. For example, if IPv6 connected successfully, we can > > increase NNN. If an IPv6 connection times out and IPv4 wins, > > we decrease NNN. This is similar to what we are doing today > > in Happy Eyeballs -00, -01, and -02. But we would simplify > > this from what is described in Happy Eyeballs today (which > > has a Tolerance Interval and suchlike, based on previous > > feedback). > > > > > > Any thoughts on the various ideas above? > > > > -d > > > > > > _______________________________________________ > > 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 On Jun 18, 2011 6:54 AM, "Brian E Carpenter" wrote: > I prefer > >> a. initiate two simultaneous connection attempts > > or even three. Some studies we've done on SHIM6/REAP and MPTCP performance > suggest that probing up to 3 addresses in parallel doesn't create > a significant load but does improve the time to establish a connection. > > Regards > Brian > > On 2011-06-18 12:25, Dan Wing wrote: >> Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the >> feedback we have received is along the lines of: >> >> * simplify further >> * don't worry about sending excessive packets >> * prefer IPv6, unless it's failing "a lot" >> >> To that end, there seem to be three approaches. We would like >> feedback on which direction to document: >> >> After calling getaddrinfo(), v6ops needs to decide if we should: >> a. initiate two simultaneous connection attempts (first IPv6 >> address and first IPv4 address). Both connections can be used >> by HTTP. Subsequent connections to that same hostname would >> use whichever address family connected quicker. >> b. initiate one connection attempt to the first address returned. >> If it isn't successful after NNN milliseconds, initiate a >> connection attempt to the first IPv4 address returned by >> getaddrinfo(). (This is what Chrome is doing.) >> c. initiate one connection attempt to the first address returned. >> If it isn't successful after NNN milliseconds, initiate a >> connection attempt to the next address returned by >> getaddrinfo(). >> >> To deal with cases where "IPv6 is failing a lot", we might consider >> ways to pick a good initial "NNN" value. For example, we might >> use a default of 200-300ms, and also define a DHCPv6 option so >> the network could convey a different default. This seems >> useful for all sorts of situations, most notably 3G wireless >> (which wouldn't use DHCPv6, but could use the same idea to >> provide the same sort of information in IPCP or whatever it >> likes.) >> >> We might also consider ways to automatically tune NNN up or >> down. For example, if IPv6 connected successfully, we can >> increase NNN. If an IPv6 connection times out and IPv4 wins, >> we decrease NNN. This is similar to what we are doing today >> in Happy Eyeballs -00, -01, and -02. But we would simplify >> this from what is described in Happy Eyeballs today (which >> has a Tolerance Interval and suchlike, based on previous >> feedback). >> >> >> Any thoughts on the various ideas above? >> >> -d >> >> >> _______________________________________________ >> 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 --000e0cdff822c80ea204a5fd92ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jun 18, 2011 6:54 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: >
> I prefer
>
> > a. initiate two simultaneous connection attempts
>
> or even three. Some studies we've done on SHIM6/REAP and MPTCP per= formance
> suggest that probing up to 3 addresses in parallel doesn't create<= br> > a significant load but does improve the time to establish a connection= .
>

Just like cell phones that constantly turn off and on their data connect= ions to optimize battery life, but in turn wreck the network with a flood o= f signalling to attach and detach.

Please no.

Some of us are thinking about cgn exit strategies, and these ipv4 connec= tions will be enough noise that I cannot properly dimension the ramp down.<= /p>

Sorry, we cannot always engineer the system to optimize on just the user= experience and expect all the other elements to scale and perform well. I = know there may be some backoff mechanism and affinity, but this is a slippe= ry slope where implementers will look to "improve " on a good ide= a to make their product look better. I do not look forward to my HE refrige= rator sending out simultaneous connections to upload my grocery list to the= cloud.

Cb

> Regards
> =A0 Brian
>
> On 2011-06-18 12:25, Dan Wing wrote:
> > Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the<= br> > > feedback we have received is along the lines of:
> >
> > =A0 * simplify further
> > =A0 * don't worry about sending excessive packets
> > =A0 * prefer IPv6, unless it's failing "a lot"
> >
> > To that end, there seem to be three approaches. =A0We would like<= br> > > feedback on which direction to document:
> >
> > After calling getaddrinfo(), v6ops needs to decide if we should:<= br> > > =A0 =A0 a. initiate two simultaneous connection attempts (first I= Pv6
> > =A0 =A0 =A0 =A0address and first IPv4 address). =A0Both connectio= ns can be used
> > =A0 =A0 =A0 =A0by HTTP. =A0Subsequent connections to that same ho= stname would
> > =A0 =A0 =A0 =A0use whichever address family connected quicker. > > =A0 =A0 b. initiate one connection attempt to the first address r= eturned.
> > =A0 =A0 =A0 =A0If it isn't successful after NNN milliseconds,= initiate a
> > =A0 =A0 =A0 =A0connection attempt to the first IPv4 address retur= ned by
> > =A0 =A0 =A0 =A0getaddrinfo(). =A0(This is what Chrome is doing.)<= br> > > =A0 =A0 c. initiate one connection attempt to the first address r= eturned.
> > =A0 =A0 =A0 =A0If it isn't successful after NNN milliseconds,= initiate a
> > =A0 =A0 =A0 =A0connection attempt to the next address returned by=
> > =A0 =A0 =A0 =A0getaddrinfo().
> >
> > To deal with cases where "IPv6 is failing a lot", we mi= ght consider
> > ways to pick a good initial "NNN" value. =A0For example= , we might
> > use a default of 200-300ms, and also define a DHCPv6 option so > > the network could convey a different default. =A0 This seems
> > useful for all sorts of situations, most notably 3G wireless
> > (which wouldn't use DHCPv6, but could use the same idea to > > provide the same sort of information in IPCP or whatever it
> > likes.)
> >
> > We might also consider ways to automatically tune NNN up or
> > down. =A0For example, if IPv6 connected successfully, we can
> > increase NNN. =A0If an IPv6 connection times out and IPv4 wins, > > we decrease NNN. =A0This is similar to what we are doing today > > in Happy Eyeballs -00, -01, and -02. =A0But we would simplify
> > this from what is described in Happy Eyeballs today (which
> > has a Tolerance Interval and suchlike, based on previous
> > feedback).
> >
> >
> > Any thoughts on the various ideas above?
> >
> > -d
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops
> >
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

On Jun 18, 2011 6:54 AM, "Brian E Carpenter= " <brian.e.carpenter= @gmail.com> wrote:
> I prefer
> >> a. initiate two simultaneous connection attempts
>
>= or even three. Some studies we've done on SHIM6/REAP and MPTCP perform= ance
> suggest that probing up to 3 addresses in parallel doesn't= create
> a significant load but does improve the time to establish a connection= .
>
> Regards
> Brian
>
> On 2011-06-18 = 12:25, Dan Wing wrote:
>> Since publishing draft-ietf-v6ops-happy-= eyeballs-02, most of the
>> feedback we have received is along the lines of:
>>
&= gt;> * simplify further
>> * don't worry about sending = excessive packets
>> * prefer IPv6, unless it's failing &quo= t;a lot"
>>
>> To that end, there seem to be three approaches. We w= ould like
>> feedback on which direction to document:
>> =
>> After calling getaddrinfo(), v6ops needs to decide if we shoul= d:
>> a. initiate two simultaneous connection attempts (first IPv6>> address and first IPv4 address). Both connections can be= used
>> by HTTP. Subsequent connections to that same host= name would
>> use whichever address family connected quicker.
>>= b. initiate one connection attempt to the first address returned.
&= gt;> If it isn't successful after NNN milliseconds, initiate = a
>> connection attempt to the first IPv4 address returned by>> getaddrinfo(). (This is what Chrome is doing.)
>>= ; c. initiate one connection attempt to the first address returned.
>> If it isn't successful after NNN milliseconds, initiate= a
>> connection attempt to the next address returned by>> getaddrinfo().
>>
>> To deal with cases= where "IPv6 is failing a lot", we might consider
>> ways to pick a good initial "NNN" value. For example, w= e might
>> use a default of 200-300ms, and also define a DHCPv6 op= tion so
>> the network could convey a different default. This s= eems
>> useful for all sorts of situations, most notably 3G wireless
&= gt;> (which wouldn't use DHCPv6, but could use the same idea to
&= gt;> provide the same sort of information in IPCP or whatever it
>> likes.)
>>
>> We might also consider ways to au= tomatically tune NNN up or
>> down. For example, if IPv6 connect= ed successfully, we can
>> increase NNN. If an IPv6 connection ti= mes out and IPv4 wins,
>> we decrease NNN. This is similar to what we are doing today
&g= t;> in Happy Eyeballs -00, -01, and -02. But we would simplify
>&= gt; this from what is described in Happy Eyeballs today (which
>> = has a Tolerance Interval and suchlike, based on previous
>> feedback).
>>
>>
>> Any thoughts on= the various ideas above?
>>
>> -d
>>
>&= gt;
>> _______________________________________________
>>= ; v6ops mailing list
>> v6ops@ietf.org
>> <= a href=3D"https://www.ietf.org/mailman/listinfo/v6ops">https://www.ietf.org= /mailman/listinfo/v6ops
>>
> __________________________= _____________________
> v6ops mailing list
> v6ops@iet= f.org
> h= ttps://www.ietf.org/mailman/listinfo/v6ops
--000e0cdff822c80ea204a5fd92ae-- From cb.list6@gmail.com Sat Jun 18 07:47:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26F611E80E9 for ; Sat, 18 Jun 2011 07:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k43OPdfX5fh0 for ; Sat, 18 Jun 2011 07:47:40 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4953511E80E7 for ; Sat, 18 Jun 2011 07:47:39 -0700 (PDT) Received: by wyj26 with SMTP id 26so232883wyj.31 for ; Sat, 18 Jun 2011 07:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=P0ad3pdK9XFJMvpd88BW6gYHekcSnW2aINsvZhZTHcM=; b=wKfdoAYLlX7opXnxjhi0GbKc9HzOW7qnCEdMjf7ydJbVPh3qaz+vb5SqBwci5BOkKV cjv8Ns4LsZK1i23KU+BMbTwXqDV8UDi+vZ8Z3Lc/5fkwT82Y5vLMNalOhphOCwt94Zel Isy/fay6xhhxwLv7CwgSMS8uNsmWD2M5XvXAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Tu9Ch/VvCY0eEdcQU2LozhIYUhnFTTmh8uvGRb6lrGw5FOOX1mpg1OEmJte3twRI+F 5HwDYEulf3+wyWswM5O/OS3PmKfQ5/jY9Tx2CSaST86X7pX2Uzioqait98YfnhiEsL3B ikPKQQEOCblDwZaTzbjWB27r7FoccQxtIGzLo= MIME-Version: 1.0 Received: by 10.216.52.193 with SMTP id e43mr233401wec.40.1308408456821; Sat, 18 Jun 2011 07:47:36 -0700 (PDT) Received: by 10.216.165.82 with HTTP; Sat, 18 Jun 2011 07:47:36 -0700 (PDT) Received: by 10.216.165.82 with HTTP; Sat, 18 Jun 2011 07:47:36 -0700 (PDT) Date: Sat, 18 Jun 2011 07:47:36 -0700 Message-ID: From: Cameron Byrne To: Brian E Carpenter Content-Type: multipart/alternative; boundary=0016e6dee70f4a3bd104a5fd952b Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 14:47:40 -0000 --0016e6dee70f4a3bd104a5fd952b Content-Type: text/plain; charset=ISO-8859-1 On Jun 18, 2011 6:54 AM, "Brian E Carpenter" wrote: > > I prefer > > > a. initiate two simultaneous connection attempts > > or even three. Some studies we've done on SHIM6/REAP and MPTCP performance > suggest that probing up to 3 addresses in parallel doesn't create > a significant load but does improve the time to establish a connection. > Just like cell phones that constantly turn off and on their data connections to optimize battery life, but in turn wreck the network with a flood of signalling to attach and detach. Please no. Some of us are thinking about cgn exit strategies, and these ipv4 connections will be enough noise that I cannot properly dimension the ramp down. Sorry, we cannot always engineer the system to optimize on just the user experience and expect all the other elements to scale and perform well Cb > Regards > Brian > > On 2011-06-18 12:25, Dan Wing wrote: > > Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the > > feedback we have received is along the lines of: > > > > * simplify further > > * don't worry about sending excessive packets > > * prefer IPv6, unless it's failing "a lot" > > > > To that end, there seem to be three approaches. We would like > > feedback on which direction to document: > > > > After calling getaddrinfo(), v6ops needs to decide if we should: > > a. initiate two simultaneous connection attempts (first IPv6 > > address and first IPv4 address). Both connections can be used > > by HTTP. Subsequent connections to that same hostname would > > use whichever address family connected quicker. > > b. initiate one connection attempt to the first address returned. > > If it isn't successful after NNN milliseconds, initiate a > > connection attempt to the first IPv4 address returned by > > getaddrinfo(). (This is what Chrome is doing.) > > c. initiate one connection attempt to the first address returned. > > If it isn't successful after NNN milliseconds, initiate a > > connection attempt to the next address returned by > > getaddrinfo(). > > > > To deal with cases where "IPv6 is failing a lot", we might consider > > ways to pick a good initial "NNN" value. For example, we might > > use a default of 200-300ms, and also define a DHCPv6 option so > > the network could convey a different default. This seems > > useful for all sorts of situations, most notably 3G wireless > > (which wouldn't use DHCPv6, but could use the same idea to > > provide the same sort of information in IPCP or whatever it > > likes.) > > > > We might also consider ways to automatically tune NNN up or > > down. For example, if IPv6 connected successfully, we can > > increase NNN. If an IPv6 connection times out and IPv4 wins, > > we decrease NNN. This is similar to what we are doing today > > in Happy Eyeballs -00, -01, and -02. But we would simplify > > this from what is described in Happy Eyeballs today (which > > has a Tolerance Interval and suchlike, based on previous > > feedback). > > > > > > Any thoughts on the various ideas above? > > > > -d > > > > > > _______________________________________________ > > 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 --0016e6dee70f4a3bd104a5fd952b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jun 18, 2011 6:54 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: >
> I prefer
>
> > a. initiate two simultaneous connection attempts
>
> or even three. Some studies we've done on SHIM6/REAP and MPTCP per= formance
> suggest that probing up to 3 addresses in parallel doesn't create<= br> > a significant load but does improve the time to establish a connection= .
>

Just like cell phones that constantly turn off and on their data connect= ions to optimize battery life, but in turn wreck the network with a flood o= f signalling to attach and detach.

Please no.

Some of us are thinking about cgn exit strategies, and these ipv4 connec= tions will be enough noise that I cannot properly dimension the ramp down.<= /p>

Sorry, we cannot always engineer the system to optimize on just the user= experience and expect all the other elements to scale and perform well

Cb

> Regards
> =A0 Brian
>
> On 2011-06-18 12:25, Dan Wing wrote:
> > Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the<= br> > > feedback we have received is along the lines of:
> >
> > =A0 * simplify further
> > =A0 * don't worry about sending excessive packets
> > =A0 * prefer IPv6, unless it's failing "a lot"
> >
> > To that end, there seem to be three approaches. =A0We would like<= br> > > feedback on which direction to document:
> >
> > After calling getaddrinfo(), v6ops needs to decide if we should:<= br> > > =A0 =A0 a. initiate two simultaneous connection attempts (first I= Pv6
> > =A0 =A0 =A0 =A0address and first IPv4 address). =A0Both connectio= ns can be used
> > =A0 =A0 =A0 =A0by HTTP. =A0Subsequent connections to that same ho= stname would
> > =A0 =A0 =A0 =A0use whichever address family connected quicker. > > =A0 =A0 b. initiate one connection attempt to the first address r= eturned.
> > =A0 =A0 =A0 =A0If it isn't successful after NNN milliseconds,= initiate a
> > =A0 =A0 =A0 =A0connection attempt to the first IPv4 address retur= ned by
> > =A0 =A0 =A0 =A0getaddrinfo(). =A0(This is what Chrome is doing.)<= br> > > =A0 =A0 c. initiate one connection attempt to the first address r= eturned.
> > =A0 =A0 =A0 =A0If it isn't successful after NNN milliseconds,= initiate a
> > =A0 =A0 =A0 =A0connection attempt to the next address returned by=
> > =A0 =A0 =A0 =A0getaddrinfo().
> >
> > To deal with cases where "IPv6 is failing a lot", we mi= ght consider
> > ways to pick a good initial "NNN" value. =A0For example= , we might
> > use a default of 200-300ms, and also define a DHCPv6 option so > > the network could convey a different default. =A0 This seems
> > useful for all sorts of situations, most notably 3G wireless
> > (which wouldn't use DHCPv6, but could use the same idea to > > provide the same sort of information in IPCP or whatever it
> > likes.)
> >
> > We might also consider ways to automatically tune NNN up or
> > down. =A0For example, if IPv6 connected successfully, we can
> > increase NNN. =A0If an IPv6 connection times out and IPv4 wins, > > we decrease NNN. =A0This is similar to what we are doing today > > in Happy Eyeballs -00, -01, and -02. =A0But we would simplify
> > this from what is described in Happy Eyeballs today (which
> > has a Tolerance Interval and suchlike, based on previous
> > feedback).
> >
> >
> > Any thoughts on the various ideas above?
> >
> > -d
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops
> >
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--0016e6dee70f4a3bd104a5fd952b-- From martin@millnert.se Sat Jun 18 10:29:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565FF11E81C0 for ; Sat, 18 Jun 2011 10:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nD5zWaa61WEU for ; Sat, 18 Jun 2011 10:29:49 -0700 (PDT) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfa.amsl.com (Postfix) with ESMTP id 230AB11E8084 for ; Sat, 18 Jun 2011 10:29:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 27C617624; Sat, 18 Jun 2011 19:52:44 +0200 (CEST) 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 tRd66e6DN1cG; Sat, 18 Jun 2011 19:52:44 +0200 (CEST) Received: from [95.80.44.186] (unknown [95.80.44.186]) by ncis.csbnet.se (Postfix) with ESMTPSA id 69D273AA; Sat, 18 Jun 2011 19:52:43 +0200 (CEST) From: Martin Millnert To: Cameron Byrne In-Reply-To: References: <007101cc2d4e$473e8380$d5bb8a80$@com> <4DFCADEA.4080100@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 18 Jun 2011 19:29:42 +0200 Message-ID: <1308418182.7094.19.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] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 17:29:50 -0000 Cameron, On Sat, 2011-06-18 at 07:46 -0700, Cameron Byrne wrote: > > On Jun 18, 2011 6:54 AM, "Brian E Carpenter" > wrote: > > > > I prefer > > > > > a. initiate two simultaneous connection attempts > Some of us are thinking about cgn exit strategies, and these ipv4 > connections will be enough noise that I cannot properly dimension the > ramp down. > > Sorry, we cannot always engineer the system to optimize on just the > user experience and expect all the other elements to scale and perform > well. I know there may be some backoff mechanism and affinity, but > this is a slippery slope where implementers will look to "improve " on > a good idea to make their product look better. I do not look forward > to my HE refrigerator sending out simultaneous connections to upload > my grocery list to the cloud. I thought it is unavoidable that LSN/CGN implies significant state load. And that the way out is per-connection-stateless IPv6 forwarding. Thus, if your HE refrigerator sits on a home LAN with IPv6-only, the 1-connection-per-AF factor will only result in 1 connection regardless. User/usage-driven cost explosion of CGN and/or poor v4 user experience is not a bad thing in and of itself IMO. That it may help provide the necessary drivers for operators to more seriously push IPv6 is only a side-effect of the state vs no-state cases of v4/v6. It's a flaw of NAT to me -- the real limits of multiple-connection-attempts/connection ought to come from the end-hosts, not the transport / internet layer itself (if they do something is wrong and should gracefully be fixed). Telco networks with a O(10) to O(100) unnecessary/necessary boxes/elements ratio (ie., the signaling/state costs you speak of) shouldn't stop a positive evolution of the internet protocols as a whole IMO: Remove the unnecessary elements instead. :) (gosh) We shouldn't optimize after the poorest designs, where 'good design' === #boxes -> 0. Kind Regards, Martin From Ted.Lemon@nominum.com Sat Jun 18 10:40:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C9821F8561 for ; Sat, 18 Jun 2011 10:40:03 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZPPCXTforHE for ; Sat, 18 Jun 2011 10:40:02 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A833921F855B for ; Sat, 18 Jun 2011 10:40:02 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTfzi8QSIZv/nE/Us75FKbwxPtJxnEzmm@postini.com; Sat, 18 Jun 2011 10:40:02 PDT 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 7E8961B85E0 for ; Sat, 18 Jun 2011 10:40:01 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 46B62190064; Sat, 18 Jun 2011 10:40:01 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([169.254.1.65]) by CAS-02.WIN.NOMINUM.COM ([169.254.98.200]) with mapi id 14.01.0289.001; Sat, 18 Jun 2011 10:40:00 -0700 From: Ted Lemon To: Cameron Byrne Thread-Topic: [v6ops] simplfying Happy Eyeballs further Thread-Index: AQHMLcapUOlQkVa2S6yr1ZMfIlYYeJTDYfFG Date: Sat, 18 Jun 2011 17:39:59 +0000 Message-ID: <740C55EE-C6E1-4681-99B3-00171C6DB1EF@nominum.com> References: 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: "v6ops@ietf.org" Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 17:40:03 -0000 On Jun 18, 2011, at 10:48 AM, "Cameron Byrne" wrote: > Some of us are thinking about cgn exit strategies, and these ipv4 connect= ions will be enough noise that I cannot properly dimension the ramp down. Why would you expect to see additional connection attempts on the CGN? Don= 't v4-only clients already launch multiple connections?= From brian.e.carpenter@gmail.com Sat Jun 18 10:53:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6126411E80F9 for ; Sat, 18 Jun 2011 10:53:43 -0700 (PDT) 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=-0.142, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-JobMpfFIrJ for ; Sat, 18 Jun 2011 10:53:42 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id EFDDD11E8084 for ; Sat, 18 Jun 2011 10:53:41 -0700 (PDT) Received: by fxm11 with SMTP id 11so1530265fxm.27 for ; Sat, 18 Jun 2011 10:53:41 -0700 (PDT) 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=jNWgladETBwxqQfOVwjItaNYYtdOm8e0IrlP0HMKD5Y=; b=uFss31cybCFO2NT5UKtijVmoNNEICSsJQxc+q+l+2CeDeptCaqD6W8G81186Bsv04+ CkPISxtsqz8b7aht0du3sRNWJUEBcsZbPP9hipMPmoIUELbXynWiRuA6ycYlo/Kkqm5b 3Lr6W+G6op19dDXk+aiV3a6grRYtg4wXSjXIg= 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=YFmr9QUdHC+pTlkno+qYNHeGp9K9ILlVlBF/F2z8mqdEaQmWmWPcVtkXFCrQLEEhe5 7/yAPNCVsFHfl+WDdk8FkNFp6TyPV4ml/5JKkvo06dGChqUFPChuMvesdw8nzYghNuYQ jkflFK3zFnIBqBI2VJiLryeHy8USWM4pVb9GU= Received: by 10.223.55.27 with SMTP id s27mr3950497fag.121.1308419621086; Sat, 18 Jun 2011 10:53:41 -0700 (PDT) Received: from [10.255.25.96] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id q21sm1910351fan.40.2011.06.18.10.53.38 (version=SSLv3 cipher=OTHER); Sat, 18 Jun 2011 10:53:39 -0700 (PDT) Message-ID: <4DFCE61E.6000902@gmail.com> Date: Sun, 19 Jun 2011 05:53:34 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cameron Byrne References: <007101cc2d4e$473e8380$d5bb8a80$@com> <4DFCADEA.4080100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 17:53:43 -0000 On 2011-06-19 02:46, Cameron Byrne wrote: > On Jun 18, 2011 6:54 AM, "Brian E Carpenter" > wrote: >> I prefer >> >>> a. initiate two simultaneous connection attempts >> or even three. Some studies we've done on SHIM6/REAP and MPTCP performance >> suggest that probing up to 3 addresses in parallel doesn't create >> a significant load but does improve the time to establish a connection. >> > > Just like cell phones that constantly turn off and on their data connections > to optimize battery life, but in turn wreck the network with a flood of > signalling to attach and detach. I agree that flooding is not ideal from an operator's PoV. However, the users' PoV matters too, and assuming the results are cached for a reasonable length of time, I seriously doubt that the negative effect will be significant. (Once MPTCP gets deployed, this will happen anyway, since it always uses multiple addresses.) Brian > Please no. > > Some of us are thinking about cgn exit strategies, and these ipv4 > connections will be enough noise that I cannot properly dimension the ramp > down. > > Sorry, we cannot always engineer the system to optimize on just the user > experience and expect all the other elements to scale and perform well. I > know there may be some backoff mechanism and affinity, but this is a > slippery slope where implementers will look to "improve " on a good idea to > make their product look better. I do not look forward to my HE refrigerator > sending out simultaneous connections to upload my grocery list to the cloud. > > > Cb > >> Regards >> Brian >> >> On 2011-06-18 12:25, Dan Wing wrote: >>> Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the >>> feedback we have received is along the lines of: >>> >>> * simplify further >>> * don't worry about sending excessive packets >>> * prefer IPv6, unless it's failing "a lot" >>> >>> To that end, there seem to be three approaches. We would like >>> feedback on which direction to document: >>> >>> After calling getaddrinfo(), v6ops needs to decide if we should: >>> a. initiate two simultaneous connection attempts (first IPv6 >>> address and first IPv4 address). Both connections can be used >>> by HTTP. Subsequent connections to that same hostname would >>> use whichever address family connected quicker. >>> b. initiate one connection attempt to the first address returned. >>> If it isn't successful after NNN milliseconds, initiate a >>> connection attempt to the first IPv4 address returned by >>> getaddrinfo(). (This is what Chrome is doing.) >>> c. initiate one connection attempt to the first address returned. >>> If it isn't successful after NNN milliseconds, initiate a >>> connection attempt to the next address returned by >>> getaddrinfo(). >>> >>> To deal with cases where "IPv6 is failing a lot", we might consider >>> ways to pick a good initial "NNN" value. For example, we might >>> use a default of 200-300ms, and also define a DHCPv6 option so >>> the network could convey a different default. This seems >>> useful for all sorts of situations, most notably 3G wireless >>> (which wouldn't use DHCPv6, but could use the same idea to >>> provide the same sort of information in IPCP or whatever it >>> likes.) >>> >>> We might also consider ways to automatically tune NNN up or >>> down. For example, if IPv6 connected successfully, we can >>> increase NNN. If an IPv6 connection times out and IPv4 wins, >>> we decrease NNN. This is similar to what we are doing today >>> in Happy Eyeballs -00, -01, and -02. But we would simplify >>> this from what is described in Happy Eyeballs today (which >>> has a Tolerance Interval and suchlike, based on previous >>> feedback). >>> >>> >>> Any thoughts on the various ideas above? >>> >>> -d >>> >>> >>> _______________________________________________ >>> 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 > On Jun 18, 2011 6:54 AM, "Brian E Carpenter" > wrote: >> I prefer >> >>> a. initiate two simultaneous connection attempts >> or even three. Some studies we've done on SHIM6/REAP and MPTCP performance >> suggest that probing up to 3 addresses in parallel doesn't create >> a significant load but does improve the time to establish a connection. >> >> Regards >> Brian >> >> On 2011-06-18 12:25, Dan Wing wrote: >>> Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the >>> feedback we have received is along the lines of: >>> >>> * simplify further >>> * don't worry about sending excessive packets >>> * prefer IPv6, unless it's failing "a lot" >>> >>> To that end, there seem to be three approaches. We would like >>> feedback on which direction to document: >>> >>> After calling getaddrinfo(), v6ops needs to decide if we should: >>> a. initiate two simultaneous connection attempts (first IPv6 >>> address and first IPv4 address). Both connections can be used >>> by HTTP. Subsequent connections to that same hostname would >>> use whichever address family connected quicker. >>> b. initiate one connection attempt to the first address returned. >>> If it isn't successful after NNN milliseconds, initiate a >>> connection attempt to the first IPv4 address returned by >>> getaddrinfo(). (This is what Chrome is doing.) >>> c. initiate one connection attempt to the first address returned. >>> If it isn't successful after NNN milliseconds, initiate a >>> connection attempt to the next address returned by >>> getaddrinfo(). >>> >>> To deal with cases where "IPv6 is failing a lot", we might consider >>> ways to pick a good initial "NNN" value. For example, we might >>> use a default of 200-300ms, and also define a DHCPv6 option so >>> the network could convey a different default. This seems >>> useful for all sorts of situations, most notably 3G wireless >>> (which wouldn't use DHCPv6, but could use the same idea to >>> provide the same sort of information in IPCP or whatever it >>> likes.) >>> >>> We might also consider ways to automatically tune NNN up or >>> down. For example, if IPv6 connected successfully, we can >>> increase NNN. If an IPv6 connection times out and IPv4 wins, >>> we decrease NNN. This is similar to what we are doing today >>> in Happy Eyeballs -00, -01, and -02. But we would simplify >>> this from what is described in Happy Eyeballs today (which >>> has a Tolerance Interval and suchlike, based on previous >>> feedback). >>> >>> >>> Any thoughts on the various ideas above? >>> >>> -d >>> >>> >>> _______________________________________________ >>> 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 cb.list6@gmail.com Sat Jun 18 11:18:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AFF9E8025 for ; Sat, 18 Jun 2011 11:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCDeyIH+8lHZ for ; Sat, 18 Jun 2011 11:18:18 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6769E801A for ; Sat, 18 Jun 2011 11:18:18 -0700 (PDT) Received: by wyj26 with SMTP id 26so304836wyj.31 for ; Sat, 18 Jun 2011 11:18:17 -0700 (PDT) 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=OAino72COsFbuLOPRWdrKJ6LsL+pNOOHrjtNXWE/+pU=; b=rfFEVD+wR/g+S2VrTxbCa1yvv+3SsONKMIoq5oe4kYuYLka7t0djiSnpgSnbIw+rhM 3QdBn/tzi7uAZYKolDsj2iE2EkvHJp9tlMOuMaqNlMOfuIzjXQNoMSnNJk2pLvttmwvs ijDDqfmYZW7Px5rQoWh8yseej6SI/aLYC1/DE= 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=a8lqBmYk34gqPUuKrV9sBj7s+TiGfwYWW4cLgGSHmf54nXKzv2GcSCfWsNUC0M6bcn X/5rA0jbUc89DCFIsT9jRkwg41uLUKc/OEpu9fzIFBl+2N2nV7yuF3Ggg8qvqL0WO09D oJ+fh9PR3w0VllHEyqPCLrIhW7DAaNeD066Ug= MIME-Version: 1.0 Received: by 10.217.1.212 with SMTP id n62mr346933wes.25.1308421097589; Sat, 18 Jun 2011 11:18:17 -0700 (PDT) Received: by 10.216.165.82 with HTTP; Sat, 18 Jun 2011 11:18:17 -0700 (PDT) In-Reply-To: <1308418182.7094.19.camel@shakira.millnert.se> References: <007101cc2d4e$473e8380$d5bb8a80$@com> <4DFCADEA.4080100@gmail.com> <1308418182.7094.19.camel@shakira.millnert.se> Date: Sat, 18 Jun 2011 11:18:17 -0700 Message-ID: From: Cameron Byrne To: Martin Millnert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 18:18:19 -0000 On Sat, Jun 18, 2011 at 10:29 AM, Martin Millnert wrot= e: > Cameron, > > On Sat, 2011-06-18 at 07:46 -0700, Cameron Byrne wrote: >> >> On Jun 18, 2011 6:54 AM, "Brian E Carpenter" >> wrote: >> > >> > I prefer >> > >> > > a. initiate two simultaneous connection attempts > >> Some of us are thinking about cgn exit strategies, and these ipv4 >> connections will be enough noise that I cannot properly dimension the >> ramp down. >> >> Sorry, we cannot always engineer the system to optimize on just the >> user experience and expect all the other elements to scale and perform >> well. I know there may be some backoff mechanism and affinity, but >> this is a slippery slope where implementers will look to "improve " on >> a good idea to make their product look better. I do not look forward >> to my HE refrigerator sending out simultaneous connections to upload >> my grocery list to the cloud. > > I thought it is unavoidable that LSN/CGN implies significant state load. Yes. CGN does imply high load, and anyone who operates such a high load system will look for as many ways as possible to reduce said load. For example, many folks in the CGN space are interested in limiting the amount of CGN capacity a given subscriber can consume (who would need more than 20 simultaneous connections ? :) ) > And that the way out is per-connection-stateless IPv6 forwarding. We can refer to this as network nirvana. Not there yet. > =A0Thus, if your HE refrigerator sits on a home LAN with IPv6-only, the > 1-connection-per-AF factor will only result in 1 connection regardless. > HE + IPv6-only? Why bother with the HE, right? Let's assume my tablet, phone, computer, and refrigerator all run Skype and therefore require IPv4. > User/usage-driven cost explosion of CGN and/or poor v4 user experience > is not a bad thing in and of itself IMO. That it may help provide the > necessary drivers for operators to more seriously push IPv6 is only a > side-effect of the state vs no-state cases of v4/v6. > =A0It's a flaw of NAT to me -- the real limits of > multiple-connection-attempts/connection ought to come from the > end-hosts, not the transport / internet layer itself (if they do > something is wrong and should gracefully be fixed). > > Telco networks with a O(10) to O(100) unnecessary/necessary > boxes/elements ratio (ie., the signaling/state costs you speak of) > shouldn't stop a positive evolution of the internet protocols as a whole > IMO: =A0Remove the unnecessary elements instead. :) =A0(gosh) > =A0We shouldn't optimize after the poorest designs, where 'good design' > =3D=3D=3D #boxes -> 0. > My only point is that we should have more carrots for IPv6 usage (virtuous cycle of more clients, connections, peering, bw, features, AF agnostic apps ...) and without creating unneeded sticks for IPv4 (further hobbling and overloading the CGN...) I think HE is very good carrot delivery mechanism, but in the wrong hands it can add sticks (hindrances to IPv4 adoption). Let's keep in mind HE exists for the purpose of improving user experience over what it is today. That is already somewhat achieved Chrome's pre-HE implementation. Let's not "love HE to death" so that we take it from making IPv6 (dual-stack) easier to making it so that IPv6 is harder. CB > Kind Regards, > Martin > > From cb.list6@gmail.com Sat Jun 18 12:04:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4115911E81FC for ; Sat, 18 Jun 2011 12:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toh0rj9woRUR for ; Sat, 18 Jun 2011 12:04:46 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAEE11E81F7 for ; Sat, 18 Jun 2011 12:04:46 -0700 (PDT) Received: by wyj26 with SMTP id 26so318907wyj.31 for ; Sat, 18 Jun 2011 12:04:45 -0700 (PDT) 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=t/jU9xsjDJJqDvJBby43NIscd5cBjBvev59tnijqunA=; b=B59dYHPiRKfFXAdKYMc+mpOepsP41eOV3UMBf41Cz71PUFrB1eiRhV6JdK0G6ePNWC bXFJR9FOeLgTugr117tDhRbOzETXITn74+xos8LAa0TSXW+2y+4ZuKJNkt9uY/hnGEsD ifdJR8PGEESIC2L6mTOu6S5iDdEO4MftceTPI= 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=MgD5DZitvV52eSAraDuTyeFPpNv7UoQWCbF9ppeAdIc6AKUTbzE5iuV7uhPqM09O5h o8pSllf38zlTON09vyIzMp8LgqyPK4ChrAE0AZnUgN4EGsM/TrT3LlcROC67VAyUdnyE WuE8MPK2yYsHK/OtPNhLwiNL3QPpHW57TBHUg= MIME-Version: 1.0 Received: by 10.217.1.212 with SMTP id n62mr370044wes.25.1308423885704; Sat, 18 Jun 2011 12:04:45 -0700 (PDT) Received: by 10.216.165.82 with HTTP; Sat, 18 Jun 2011 12:04:45 -0700 (PDT) In-Reply-To: <740C55EE-C6E1-4681-99B3-00171C6DB1EF@nominum.com> References: <740C55EE-C6E1-4681-99B3-00171C6DB1EF@nominum.com> Date: Sat, 18 Jun 2011 12:04:45 -0700 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] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 19:04:47 -0000 On Sat, Jun 18, 2011 at 10:39 AM, Ted Lemon wrote: > On Jun 18, 2011, at 10:48 AM, "Cameron Byrne" wrote: >> Some of us are thinking about cgn exit strategies, and these ipv4 connec= tions will be enough noise that I cannot properly dimension the ramp down. > > Why would you expect to see additional connection attempts on the CGN? = =A0Don't v4-only clients already launch multiple connections? Yes. I am only scoping HE in my head for scenarios where the resources are dual-stack on both sides, thus there is an opportunity for a v6 e2e connection which can result in a net reduction in the v4 connection growth rate if the v6 connection quality is "ok" (that said, v4 connection growth rate is still very very high, and any help in reducing it is advantageous to the CGN operator). CB From pch-b2B3A6689@u-1.phicoh.com Sat Jun 18 15:47:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C57111E80ED for ; Sat, 18 Jun 2011 15:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8G7iBTwnua3 for ; Sat, 18 Jun 2011 15:47:14 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6656611E80BC for ; Sat, 18 Jun 2011 15:47:13 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QY4IG-0001i3C; Sun, 19 Jun 2011 00:47:08 +0200 Message-Id: To: Cameron Byrne From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <740C55EE-C6E1-4681-99B3-00171C6DB1EF@nominum.com> In-reply-to: Your message of "Sat, 18 Jun 2011 12:04:45 -0700 ." Date: Sun, 19 Jun 2011 00:46:51 +0200 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 22:47:15 -0000 In your letter dated Sat, 18 Jun 2011 12:04:45 -0700 you wrote: >I am only scoping HE in my head for scenarios where the resources are >dual-stack on both sides, thus there is an opportunity for a v6 e2e >connection which can result in a net reduction in the v4 connection >growth rate if the v6 connection quality is "ok" (that said, v4 >connection growth rate is still very very high, and any help in >reducing it is advantageous to the CGN operator). Yes. If you do HE as 'just an IPv4 and an IPv6 connect at the same time' then any increase dual stack support will never result in a reduction of the number of IPv4 connection attempts. So in my opinion, it is important that HE will avoid an IPv4 connect if an IPv6 is likely to work well. From tsavo.stds@gmail.com Mon Jun 20 05:53:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158E911E8174 for ; Mon, 20 Jun 2011 05:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6A78tmQI25I for ; Mon, 20 Jun 2011 05:53:06 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF0F811E8170 for ; Mon, 20 Jun 2011 05:53:05 -0700 (PDT) Received: by wyj26 with SMTP id 26so1159438wyj.31 for ; Mon, 20 Jun 2011 05:53:05 -0700 (PDT) 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=/dajFpSYJ6b2rqrsGnAV8//GUGTrT3VKsBXcRE4LZFU=; b=QeQ6tzr00tQegIWrQvAuxCzveIky/M+DtTW1WfTgHfS7syCRen3T6SUIolKEjJcWS4 m1OatrlJy4DMVQV4wK42y4RmzZOguQFGmcXyy1XQyhh4jKVefoNJbkMEwqs4FviMSece HQVbBisFZQriqNH66bD2sk3aO5Wm4s2qgoP/Y= 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=jJ4Iol3MIIrLm/3tTWKTZETL68MHixDjW+yWfJAQoz+NOPz8azPKnA8TO+dS0dgrpC HstdHh8MMwxyNV4zKYtzzYmjfKKMJpCuW7DZrwy5EG1bIieDGnq9o9AH5/oPwI610f2W r72ciF+nyTx8IX1MRnyptOg4vM5VYjAFVDeIc= MIME-Version: 1.0 Received: by 10.216.237.205 with SMTP id y55mr2017505weq.49.1308574384915; Mon, 20 Jun 2011 05:53:04 -0700 (PDT) Received: by 10.216.137.90 with HTTP; Mon, 20 Jun 2011 05:53:04 -0700 (PDT) In-Reply-To: <007101cc2d4e$473e8380$d5bb8a80$@com> References: <007101cc2d4e$473e8380$d5bb8a80$@com> Date: Mon, 20 Jun 2011 15:53:04 +0300 Message-ID: From: Teemu Savolainen To: Dan Wing Content-Type: multipart/alternative; boundary=0015174beb6a6005ab04a62437a7 Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 12:53:07 -0000 --0015174beb6a6005ab04a62437a7 Content-Type: text/plain; charset=ISO-8859-1 Is the getaddrinfo the lowest sofware layer where we can go to? I mean eyeballs could be happier if the possible issues related to A and AAAA queries were included in the algorithm. It is simpler to work only after getaddrinfo has returned with both IPv4 and IPv6 addresses, but better results could be obtained if application would use API to issue separate queries for IPv4 and IPv6 addresses, and include the DNS delay in the address family selection (e.g. not wait for another DNS resolution more than YYY milliseconds after first completes). About DHCPv6 and 3G: DHCPv6 has been supported for parameter configuration for a long time, and hence this value could be delivered also in 3G with DHCPv6 if so chosen. I don't like a) due to waste I consider excess, so something that prefers IPv6 when it should work and just does very quick fallback to IPv4. So that most of the time only IPv6 connection would be created. I guess if IPv6 sometimes is delayed, it would not matter too much of IPv4 connection attempt would be launched slightly before IPv6 connection has completed. Best regards, Teemu 2011/6/18 Dan Wing > Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the > feedback we have received is along the lines of: > > * simplify further > * don't worry about sending excessive packets > * prefer IPv6, unless it's failing "a lot" > > To that end, there seem to be three approaches. We would like > feedback on which direction to document: > > After calling getaddrinfo(), v6ops needs to decide if we should: > a. initiate two simultaneous connection attempts (first IPv6 > address and first IPv4 address). Both connections can be used > by HTTP. Subsequent connections to that same hostname would > use whichever address family connected quicker. > b. initiate one connection attempt to the first address returned. > If it isn't successful after NNN milliseconds, initiate a > connection attempt to the first IPv4 address returned by > getaddrinfo(). (This is what Chrome is doing.) > c. initiate one connection attempt to the first address returned. > If it isn't successful after NNN milliseconds, initiate a > connection attempt to the next address returned by > getaddrinfo(). > > To deal with cases where "IPv6 is failing a lot", we might consider > ways to pick a good initial "NNN" value. For example, we might > use a default of 200-300ms, and also define a DHCPv6 option so > the network could convey a different default. This seems > useful for all sorts of situations, most notably 3G wireless > (which wouldn't use DHCPv6, but could use the same idea to > provide the same sort of information in IPCP or whatever it > likes.) > > We might also consider ways to automatically tune NNN up or > down. For example, if IPv6 connected successfully, we can > increase NNN. If an IPv6 connection times out and IPv4 wins, > we decrease NNN. This is similar to what we are doing today > in Happy Eyeballs -00, -01, and -02. But we would simplify > this from what is described in Happy Eyeballs today (which > has a Tolerance Interval and suchlike, based on previous > feedback). > > > Any thoughts on the various ideas above? > > -d > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0015174beb6a6005ab04a62437a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is the getaddrinfo the lowest sofware layer where we can go to? I mean eyeb= alls could be happier if the possible issues related to A and AAAA queries = were included in the algorithm. It is simpler to work only after getaddrinf= o has returned with both IPv4 and IPv6 addresses, but better results could = be obtained if application would use API to issue separate queries for IPv4= and IPv6 addresses, and include the DNS delay in the address family select= ion (e.g. not wait for another DNS resolution more than YYY milliseconds af= ter first completes).

About DHCPv6 and 3G: DHCPv6 has been supported for parameter configurat= ion for a long time, and hence this value could be delivered also in 3G wit= h DHCPv6 if so chosen.

I don't like a) due to waste I consider e= xcess, so something that prefers IPv6 when it should work and just does ver= y quick fallback to IPv4. So that most of the time only IPv6 connection wou= ld be created. I guess if IPv6 sometimes is delayed, it would not matter to= o much of IPv4 connection attempt would be launched slightly before IPv6 co= nnection has completed.

Best regards,

Teemu

2011/6/18 = Dan Wing <dwing@cis= co.com>
Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the
feedback we have received is along the lines of:

=A0* simplify further
=A0* don't worry about sending excessive packets
=A0* prefer IPv6, unless it's failing "a lot"

To that end, there seem to be three approaches. =A0We would like
feedback on which direction to document:

After calling getaddrinfo(), v6ops needs to decide if we should:
=A0 =A0a. initiate two simultaneous connection attempts (first IPv6
=A0 =A0 =A0 address and first IPv4 address). =A0Both connections can be us= ed
=A0 =A0 =A0 by HTTP. =A0Subsequent connections to that same hostname would=
=A0 =A0 =A0 use whichever address family connected quicker.
=A0 =A0b. initiate one connection attempt to the first address returned. =A0 =A0 =A0 If it isn't successful after NNN milliseconds, initiate a<= br> =A0 =A0 =A0 connection attempt to the first IPv4 address returned by
=A0 =A0 =A0 getaddrinfo(). =A0(This is what Chrome is doing.)
=A0 =A0c. initiate one connection attempt to the first address returned. =A0 =A0 =A0 If it isn't successful after NNN milliseconds, initiate a<= br> =A0 =A0 =A0 connection attempt to the next address returned by
=A0 =A0 =A0 getaddrinfo().

To deal with cases where "IPv6 is failing a lot", we might consid= er
ways to pick a good initial "NNN" value. =A0For example, we might=
use a default of 200-300ms, and also define a DHCPv6 option so
the network could convey a different default. =A0 This seems
useful for all sorts of situations, most notably 3G wireless
(which wouldn't use DHCPv6, but could use the same idea to
provide the same sort of information in IPCP or whatever it
likes.)

We might also consider ways to automatically tune NNN up or
down. =A0For example, if IPv6 connected successfully, we can
increase NNN. =A0If an IPv6 connection times out and IPv4 wins,
we decrease NNN. =A0This is similar to what we are doing today
in Happy Eyeballs -00, -01, and -02. =A0But we would simplify
this from what is described in Happy Eyeballs today (which
has a Tolerance Interval and suchlike, based on previous
feedback).


Any thoughts on the various ideas above?

-d


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--0015174beb6a6005ab04a62437a7-- From marka@isc.org Mon Jun 20 06:45:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2521011E80A2 for ; Mon, 20 Jun 2011 06:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyIQE+1YhxQk for ; Mon, 20 Jun 2011 06:45:12 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 8F16A11E8099 for ; Mon, 20 Jun 2011 06:45:11 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 280B5C94FF; Mon, 20 Jun 2011 13:45:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 7911A216C82; Mon, 20 Jun 2011 13:44:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id A4C5A10EFD10; Mon, 20 Jun 2011 23:44:57 +1000 (EST) To: Teemu Savolainen From: Mark Andrews References: <007101cc2d4e$473e8380$d5bb8a80$@com> In-reply-to: Your message of "Mon, 20 Jun 2011 15:53:04 +0300." Date: Mon, 20 Jun 2011 23:44:57 +1000 Message-Id: <20110620134457.A4C5A10EFD10@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:45:13 -0000 In message , Teemu Savolain en writes: > > Is the getaddrinfo the lowest sofware layer where we can go to? I mean > eyeballs could be happier if the possible issues related to A and AAAA > queries were included in the algorithm. It is simpler to work only after > getaddrinfo has returned with both IPv4 and IPv6 addresses, but better > results could be obtained if application would use API to issue separate > queries for IPv4 and IPv6 addresses, and include the DNS delay in the > address family selection (e.g. not wait for another DNS resolution more than > YYY milliseconds after first completes). DNS response time has absolutely nothing to do with which address family is best to use. > About DHCPv6 and 3G: DHCPv6 has been supported for parameter configuration > for a long time, and hence this value could be delivered also in 3G with > DHCPv6 if so chosen. > > I don't like a) due to waste I consider excess, so something that prefers > IPv6 when it should work and just does very quick fallback to IPv4. So that > most of the time only IPv6 connection would be created. I guess if IPv6 > sometimes is delayed, it would not matter too much of IPv4 connection > attempt would be launched slightly before IPv6 connection has completed. > > Best regards, > > Teemu > > 2011/6/18 Dan Wing > > > Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the > > feedback we have received is along the lines of: > > > > * simplify further > > * don't worry about sending excessive packets > > * prefer IPv6, unless it's failing "a lot" > > > > To that end, there seem to be three approaches. We would like > > feedback on which direction to document: > > > > After calling getaddrinfo(), v6ops needs to decide if we should: > > a. initiate two simultaneous connection attempts (first IPv6 > > address and first IPv4 address). Both connections can be used > > by HTTP. Subsequent connections to that same hostname would > > use whichever address family connected quicker. > > b. initiate one connection attempt to the first address returned. > > If it isn't successful after NNN milliseconds, initiate a > > connection attempt to the first IPv4 address returned by > > getaddrinfo(). (This is what Chrome is doing.) > > c. initiate one connection attempt to the first address returned. > > If it isn't successful after NNN milliseconds, initiate a > > connection attempt to the next address returned by > > getaddrinfo(). > > > > To deal with cases where "IPv6 is failing a lot", we might consider > > ways to pick a good initial "NNN" value. For example, we might > > use a default of 200-300ms, and also define a DHCPv6 option so > > the network could convey a different default. This seems > > useful for all sorts of situations, most notably 3G wireless > > (which wouldn't use DHCPv6, but could use the same idea to > > provide the same sort of information in IPCP or whatever it > > likes.) > > > > We might also consider ways to automatically tune NNN up or > > down. For example, if IPv6 connected successfully, we can > > increase NNN. If an IPv6 connection times out and IPv4 wins, > > we decrease NNN. This is similar to what we are doing today > > in Happy Eyeballs -00, -01, and -02. But we would simplify > > this from what is described in Happy Eyeballs today (which > > has a Tolerance Interval and suchlike, based on previous > > feedback). > > > > > > Any thoughts on the various ideas above? > > > > -d > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > --0015174beb6a6005ab04a62437a7 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Is the getaddrinfo the lowest sofware layer where we can go to? I mean eyeb= > alls could be happier if the possible issues related to A and AAAA queries = > were included in the algorithm. It is simpler to work only after getaddrinf= > o has returned with both IPv4 and IPv6 addresses, but better results could = > be obtained if application would use API to issue separate queries for IPv4= > and IPv6 addresses, and include the DNS delay in the address family select= > ion (e.g. not wait for another DNS resolution more than YYY milliseconds af= > ter first completes).
>
About DHCPv6 and 3G: DHCPv6 has been supported for parameter configurat= > ion for a long time, and hence this value could be delivered also in 3G wit= > h DHCPv6 if so chosen.

I don't like a) due to waste I consider e= > xcess, so something that prefers IPv6 when it should work and just does ver= > y quick fallback to IPv4. So that most of the time only IPv6 connection wou= > ld be created. I guess if IPv6 sometimes is delayed, it would not matter to= > o much of IPv4 connection attempt would be launched slightly before IPv6 co= > nnection has completed.
>
Best regards,

Teemu

2011/6/18 = > Dan Wing <dwing@cis= > co.com>
0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left= > : 1ex;"> > Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the
> feedback we have received is along the lines of:
>
> =A0* simplify further
> =A0* don't worry about sending excessive packets
> =A0* prefer IPv6, unless it's failing "a lot"
>
> To that end, there seem to be three approaches. =A0We would like
> feedback on which direction to document:
>
> After calling getaddrinfo(), v6ops needs to decide if we should:
> =A0 =A0a. initiate two simultaneous connection attempts (first IPv6
> =A0 =A0 =A0 address and first IPv4 address). =A0Both connections can be us= > ed
> =A0 =A0 =A0 by HTTP. =A0Subsequent connections to that same hostname would= >
> =A0 =A0 =A0 use whichever address family connected quicker.
> =A0 =A0b. initiate one connection attempt to the first address returned. r> > =A0 =A0 =A0 If it isn't successful after NNN milliseconds, initiate a<= > br> > =A0 =A0 =A0 connection attempt to the first IPv4 address returned by
> =A0 =A0 =A0 getaddrinfo(). =A0(This is what Chrome is doing.)
> =A0 =A0c. initiate one connection attempt to the first address returned. r> > =A0 =A0 =A0 If it isn't successful after NNN milliseconds, initiate a<= > br> > =A0 =A0 =A0 connection attempt to the next address returned by
> =A0 =A0 =A0 getaddrinfo().
>
> To deal with cases where "IPv6 is failing a lot", we might consid= > er
> ways to pick a good initial "NNN" value. =A0For example, we might= >
> use a default of 200-300ms, and also define a DHCPv6 option so
> the network could convey a different default. =A0 This seems
> useful for all sorts of situations, most notably 3G wireless
> (which wouldn't use DHCPv6, but could use the same idea to
> provide the same sort of information in IPCP or whatever it
> likes.)
>
> We might also consider ways to automatically tune NNN up or
> down. =A0For example, if IPv6 connected successfully, we can
> increase NNN. =A0If an IPv6 connection times out and IPv4 wins,
> we decrease NNN. =A0This is similar to what we are doing today
> in Happy Eyeballs -00, -01, and -02. =A0But we would simplify
> this from what is described in Happy Eyeballs today (which
> has a Tolerance Interval and suchlike, based on previous
> feedback).
>
>
> Any thoughts on the various ideas above?
>
> -d
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> h= > ttps://www.ietf.org/mailman/listinfo/v6ops
>

> > --0015174beb6a6005ab04a62437a7-- > > --===============2809441630508197365== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --===============2809441630508197365==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From gert@space.net Mon Jun 20 06:47:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A66B11E808B for ; Mon, 20 Jun 2011 06:47:44 -0700 (PDT) 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.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHue4uubuT5l for ; Mon, 20 Jun 2011 06:47:44 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC0E11E808A for ; Mon, 20 Jun 2011 06:47:41 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id D7EA3F84AB for ; Mon, 20 Jun 2011 15:47:36 +0200 (CEST) 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 C2931F8437 for ; Mon, 20 Jun 2011 15:47:36 +0200 (CEST) Received: (qmail 65374 invoked by uid 1007); 20 Jun 2011 15:47:36 +0200 Date: Mon, 20 Jun 2011 15:47:36 +0200 From: Gert Doering To: Mark Andrews Message-ID: <20110620134736.GC2304@Space.Net> References: <007101cc2d4e$473e8380$d5bb8a80$@com> <20110620134457.A4C5A10EFD10@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110620134457.A4C5A10EFD10@drugs.dv.isc.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:47:44 -0000 Hi, On Mon, Jun 20, 2011 at 11:44:57PM +1000, Mark Andrews wrote: > DNS response time has absolutely nothing to do with which address family > is best to use. Theoretically true, but in the face of broken auth servers that just ignore AAAA queries (= no response, resolver timeout -> delay) and other weirdness, for a *happy eyeball* it might be a good plan to try the first address family as soon as the DNS response is there. 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 marka@isc.org Mon Jun 20 07:31:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11A911E807E for ; Mon, 20 Jun 2011 07:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0oDhr8B5kgN for ; Mon, 20 Jun 2011 07:31:17 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D494A11E8073 for ; Mon, 20 Jun 2011 07:31:16 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 6A093C94C3; Mon, 20 Jun 2011 14:31:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 07D1C216C7B; Mon, 20 Jun 2011 14:31:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 3A9A110F0158; Tue, 21 Jun 2011 00:30:59 +1000 (EST) To: Gert Doering From: Mark Andrews References: <007101cc2d4e$473e8380$d5bb8a80$@com> <20110620134457.A4C5A10EFD10@drugs.dv.isc.org> <20110620134736.GC2304@Space.Net> In-reply-to: Your message of "Mon, 20 Jun 2011 15:47:36 +0200." <20110620134736.GC2304@Space.Net> Date: Tue, 21 Jun 2011 00:30:59 +1000 Message-Id: <20110620143059.3A9A110F0158@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 14:31:18 -0000 In message <20110620134736.GC2304@Space.Net>, Gert Doering writes: > Hi, > > On Mon, Jun 20, 2011 at 11:44:57PM +1000, Mark Andrews wrote: > > DNS response time has absolutely nothing to do with which address family > > is best to use. > > Theoretically true, but in the face of broken auth servers that just > ignore AAAA queries (= no response, resolver timeout -> delay) and other > weirdness, for a *happy eyeball* it might be a good plan to try the first > address family as soon as the DNS response is there. Servers which ignore AAAA queries basically disappeared from the network several years ago. There are the odd ones about but they are hard to find even when looking for them. There are servers that respond with incorrect negative responses but most of them look like configuration errors. A misconfigured full server behind a load balancing front end or parking site trying to use a parent zone to answer zones that have been delegated to it. Registries, if they were meeting their RFC 1034 requirements, would clean up the latter. They can only operate where the TLD doesn't perform sanity checks at delegation time. Also it is not hard to get nameservers that work. If a site is slow because they are running broken nameservers should we let them off the hook. Perhaps having customers complain that their site is slow will get them to fix their end. I complained to Verisign about WWW.VERISIGNINC.COM not working over IPv6 (PMTUD broken) and it was fixed within 24 hours. Sometimes the correct thing is to complain. Mark > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From pch-b2B3A6689@u-1.phicoh.com Mon Jun 20 08:17:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A67D21F85EE for ; Mon, 20 Jun 2011 08:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.449 X-Spam-Level: X-Spam-Status: No, score=-8.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9S4MFZ7jsfx for ; Mon, 20 Jun 2011 08:17:16 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id D535121F85DE for ; Mon, 20 Jun 2011 08:17:11 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QYgDk-0001gMC; Mon, 20 Jun 2011 17:17:00 +0200 Message-Id: To: Teemu Savolainen From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <007101cc2d4e$473e8380$d5bb8a80$@com> In-reply-to: Your message of "Mon, 20 Jun 2011 15:53:04 +0300 ." Date: Mon, 20 Jun 2011 17:16:55 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:17:17 -0000 In your letter dated Mon, 20 Jun 2011 15:53:04 +0300 you wrote: >Is the getaddrinfo the lowest sofware layer where we can go to? I mean >eyeballs could be happier if the possible issues related to A and AAAA >queries were included in the algorithm. It is simpler to work only after >getaddrinfo has returned with both IPv4 and IPv6 addresses, but better >results could be obtained if application would use API to issue separate >queries for IPv4 and IPv6 addresses, and include the DNS delay in the >address family selection (e.g. not wait for another DNS resolution more than >YYY milliseconds after first completes). I think that for that you would need an asynchronous DNS (stub) resolver. They exist, but I think don't there is anything close a standard API at the moment. (Multi-threading would be another option, but I don't want to go there) From joelja@bogus.com Mon Jun 20 08:44:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FED9E802F for ; Mon, 20 Jun 2011 08:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.174 X-Spam-Level: X-Spam-Status: No, score=-103.174 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkwZOMYx1P4Q for ; Mon, 20 Jun 2011 08:44:09 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A47869E8018 for ; Mon, 20 Jun 2011 08:44:08 -0700 (PDT) Received: from [172.16.25.61] ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p5KFhwQh081825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Jun 2011 15:44:01 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Mon, 20 Jun 2011 08:43:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0DFE0BED-0548-40BB-957A-09D6976AAF99@bogus.com> References: <007101cc2d4e$473e8380$d5bb8a80$@com> To: Philip Homburg X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 20 Jun 2011 15:44:02 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:44:13 -0000 On Jun 20, 2011, at 8:16 AM, Philip Homburg wrote: > In your letter dated Mon, 20 Jun 2011 15:53:04 +0300 you wrote: >> Is the getaddrinfo the lowest sofware layer where we can go to? I = mean >> eyeballs could be happier if the possible issues related to A and = AAAA >> queries were included in the algorithm. It is simpler to work only = after >> getaddrinfo has returned with both IPv4 and IPv6 addresses, but = better >> results could be obtained if application would use API to issue = separate >> queries for IPv4 and IPv6 addresses, and include the DNS delay in the >> address family selection (e.g. not wait for another DNS resolution = more than >> YYY milliseconds after first completes). >=20 > I think that for that you would need an asynchronous DNS (stub) = resolver. They > exist, but I think don't there is anything close a standard API at the > moment. (Multi-threading would be another option, but I don't want to > go there) rewiring the behavior of DNS resolvers seems like a bridge too far esp = given how little it's likely to tell you about the path between you and = the host you're going to subsequently attempt to connect to. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From simon.perreault@viagenie.ca Mon Jun 20 08:46:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9630A21F8495 for ; Mon, 20 Jun 2011 08:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tg5JA1hj6trj for ; Mon, 20 Jun 2011 08:46:40 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 4248A21F8494 for ; Mon, 20 Jun 2011 08:46:40 -0700 (PDT) Received: from [172.16.1.3] (h105.viagenie.ca [206.123.31.105]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1D94E21C25 for ; Mon, 20 Jun 2011 11:46:38 -0400 (EDT) Message-ID: <4DFF6BA3.2040201@viagenie.ca> Date: Mon, 20 Jun 2011 11:47:47 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: v6ops@ietf.org References: <007101cc2d4e$473e8380$d5bb8a80$@com> <0DFE0BED-0548-40BB-957A-09D6976AAF99@bogus.com> In-Reply-To: <0DFE0BED-0548-40BB-957A-09D6976AAF99@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:46:48 -0000 On 2011-06-20 11:43, Joel Jaeggli wrote: > rewiring the behavior of DNS resolvers seems like a bridge too far It's been available in multiple open source libraries since quite some time. One example is the venerable libevent. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From joelja@bogus.com Mon Jun 20 08:51:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0E121F84F2 for ; Mon, 20 Jun 2011 08:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QUq-fUFEnRc for ; Mon, 20 Jun 2011 08:51:35 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE6921F84ED for ; Mon, 20 Jun 2011 08:51:31 -0700 (PDT) Received: from [172.16.25.61] ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p5KFpRNl081984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Jun 2011 15:51:29 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <4DFF6BA3.2040201@viagenie.ca> Date: Mon, 20 Jun 2011 08:51:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C88B822-0AE5-4376-B011-27A5692F2B99@bogus.com> References: <007101cc2d4e$473e8380$d5bb8a80$@com> <0DFE0BED-0548-40BB-957A-09D6976AAF99@bogus.com> <4DFF6BA3.2040201@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 20 Jun 2011 15:51:29 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:51:36 -0000 On Jun 20, 2011, at 8:47 AM, Simon Perreault wrote: > On 2011-06-20 11:43, Joel Jaeggli wrote: >> rewiring the behavior of DNS resolvers seems like a bridge too far >=20 > It's been available in multiple open source libraries since quite some = time. One example is the venerable libevent. so hypothetically I ask my upstream resolver for www.google.com = seperately for A and AAAA I do this over ipv4, both results are cached = so they're delivered in more or less the same amount of time, what to I = conclude from that? does the search list in your resolv.conf further amplify the number of = queries you've got to make? > Simon > --=20 > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From v6ops@globis.net Mon Jun 20 09:42:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8686D11E80C0 for ; Mon, 20 Jun 2011 09:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV4WPu7F03In for ; Mon, 20 Jun 2011 09:42:38 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 82ECA11E80B0 for ; Mon, 20 Jun 2011 09:42:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 180578700C7; Mon, 20 Jun 2011 18:42:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhpltXgz69KN; Mon, 20 Jun 2011 18:42:30 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E1F1A870030; Mon, 20 Jun 2011 18:42:30 +0200 (CEST) Message-ID: <4DFF7876.8050306@globis.net> Date: Mon, 20 Jun 2011 18:42:30 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "v6ops@ietf.org WG" , Mark Andrews Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 16:42:38 -0000 +1 > On Mon, Jun 20, 2011 at 11:44:57PM +1000, Mark Andrews wrote: > >> > > DNS response time has absolutely nothing to do with which address family >> > > is best to use. >> On Tue, 21 Jun 2011 00:30:59 +1000, Mark Andrews wrote: > Also it is not hard to get nameservers that work. If a site is slow > because they are running broken nameservers should we let them off the > hook. Perhaps having customers complain that their site is slow will > get them to fix their end. Further, I like the idea of a straight race between IPv4 and IPv6 with some simple local storage of recent history of which address family to prefer based on measured round trip response times to the real server (not DNS). IMVHO If network operators want to turn off IPv4/CGN later in a controlled manner, they can achieve the effect of discouraging the use of IPv4/CGN compared to IPv6 by introducing some delay or configuration in their own particular CGN box / IPv4 service at a time and in a manner that suits their own particular IPv6 migration requirements, rather than trying to use an RFC to artificially cripple/influence behavior of 100% of end clients in some way on 100% of networks. Some additional queuing of IPv4 SYN packets compared to other traffic at some point within the network cloud (e.g. on the CPE/ ingress router, or the CGN service router itself) wouldn't seem that hard to do IMHO, rather than changing 100% of clients. That way IPv6 could get a head start, but only when needed at some point in time of the migration, and only in some networks that need this feature, but neither IPv4 nor IPv6 is delayed once/if the IPv4 or IPv6 session is established. At least one leading manufacturer already seems to do a good job of coupling users/ user groups to IPv4/CGN services via user profiles, so that any CGN switch off won't have to be an all or nothing process for all users at once. They could also build in that (artificial) IPv4 SYN delay on one particular CGN profile, so you can switch over to IPv6 by groups/ batches of users without changing the client at all. I recently did a complex disentanglement of interconnects where people weren't really certain what residual traffic was still running and why. As a last step, the only practical operational way forward was to really cut the wire, and have a rapid-response team in place to restore any important functionality when "important" people "peeped" to the help desk, whilst "non-important" people were told to reconfigure their apps or find another solution themselves. No technology can tell you in advance of a cut off with 100% certainty what traffic is "important", or why it's still running. People and processes are a far better solution to this type of problem. regards, RayH From simon.perreault@viagenie.ca Mon Jun 20 10:32:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE9211E817C for ; Mon, 20 Jun 2011 10:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3GwIBmABlQu for ; Mon, 20 Jun 2011 10:32:54 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 1186111E8178 for ; Mon, 20 Jun 2011 10:32:54 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CB6AE20D1F; Mon, 20 Jun 2011 13:32:52 -0400 (EDT) Message-ID: <4DFF8444.7020407@viagenie.ca> Date: Mon, 20 Jun 2011 13:32:52 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Joel Jaeggli References: <007101cc2d4e$473e8380$d5bb8a80$@com> <0DFE0BED-0548-40BB-957A-09D6976AAF99@bogus.com> <4DFF6BA3.2040201@viagenie.ca> <3C88B822-0AE5-4376-B011-27A5692F2B99@bogus.com> In-Reply-To: <3C88B822-0AE5-4376-B011-27A5692F2B99@bogus.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 17:32:55 -0000 On 2011-06-20 11:51, Joel Jaeggli wrote: > so hypothetically I ask my upstream resolver for www.google.com > seperately for A and AAAA I do this over ipv4, both results are > cached so they're delivered in more or less the same amount of time, > what to I conclude from that? Nothing. You don't make parallel DNS queries in order to conclude anything about the remote host. You make parallel queries to avoid delays when e.g. a DNS server doesn't reply to AAAA queries. It's a way to include the DNS process in the overall connection establishment process. IIRC there was a graph like this in an IAB presentation by Stuart Cheshire a few IETFs ago: +----DNS A------TCP SYN-----[finish] v4| [start]--+ v6| +----DNS AAAA---TCP SYN-----[finish] > does the search list in your resolv.conf further amplify the number > of queries you've got to make? Personally, I'd rather run a lightweight caching nameserver (e.g. Unbound) locally and let it handle upstream server failures. http://www.unbound.net/documentation/info_timeout.html Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From cb.list6@gmail.com Mon Jun 20 11:29:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCCD11E81CC for ; Mon, 20 Jun 2011 11:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEtRTAEo-MR9 for ; Mon, 20 Jun 2011 11:29:24 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7639011E81CB for ; Mon, 20 Jun 2011 11:29:24 -0700 (PDT) Received: by wwg11 with SMTP id 11so2470549wwg.1 for ; Mon, 20 Jun 2011 11:29:23 -0700 (PDT) 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=oZmIWTP5agNftQJJmeO9WKtYDGFQArZb192EJGSi4XI=; b=xFIyiAFGJ0oCgfDfU0JzXYMlO8hpgZ0nkX/HTDKfvfRTaZfqHtOATdb1Q3/3yMTGSJ 0+hm45c9ABtLcQn4dtHUr7bJDagg4BgFSAMqfk5jY4HTIJoDxdr6mQVeWuKQjwoY2hOa dtMPXAtmKPU/aPLR/j0Qw4pRX554MbrACq9BE= 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=PujdEgzg4eRMHTOS1iVUHTcEVRsXJEAdBIUB2FvCVsQvCW7B9+UFLTRwpMDxlRMMIb 0CjM17ZiMnkk+YWFr+JeL3795nVl8ky3JkCtdsRV9RJxscety5pMRZFp9BpKYdB2ewix ATnMQ/UCbdyEExsB9y1GGrRLPeE6y/zgSPyss= MIME-Version: 1.0 Received: by 10.217.1.212 with SMTP id n62mr2346605wes.25.1308594563453; Mon, 20 Jun 2011 11:29:23 -0700 (PDT) Received: by 10.216.165.82 with HTTP; Mon, 20 Jun 2011 11:29:23 -0700 (PDT) In-Reply-To: <4DFF7876.8050306@globis.net> References: <4DFF7876.8050306@globis.net> Date: Mon, 20 Jun 2011 11:29:23 -0700 Message-ID: From: Cameron Byrne To: Ray Hunter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 18:29:25 -0000 On Mon, Jun 20, 2011 at 9:42 AM, Ray Hunter wrote: > +1 >> >> On Mon, Jun 20, 2011 at 11:44:57PM +1000, Mark Andrews wrote: >> >>> >>> > =A0> =A0DNS response time has absolutely nothing to do with which add= ress >>> > family >>> > =A0> =A0is best to use. >>> > > On Tue, 21 Jun 2011 00:30:59 +1000, Mark Andrews wrote: >> >> Also it is not hard to get nameservers that work. If a site is slow >> because they are running broken nameservers should we let them off the h= ook. >> Perhaps having customers complain that their site is slow will get them = to >> fix their end. > > Further, I like the idea of a straight race between IPv4 and IPv6 with so= me > simple local storage of recent history of which address family to prefer > based on measured round trip response times to the real server (not DNS). > > > IMVHO If network operators want to turn off IPv4/CGN later in a controlle= d > manner, they can achieve the effect of discouraging the use of IPv4/CGN > compared to IPv6 by introducing some delay or configuration in their own > particular CGN box / IPv4 service at a time and in a manner that suits th= eir This is very unlikely that an SP would inject latency like this. In fact, it is completely unrealistic from a business and instrumentation perspective. > own particular IPv6 migration requirements, rather than trying to use an = RFC > to artificially cripple/influence behavior of 100% of end clients in some > way on 100% of networks. > Generally, i like e2e solutions, not middle box manipulation. > Some additional queuing of IPv4 SYN packets compared to other traffic at > some point within the network cloud (e.g. on the CPE/ ingress router, or = the > CGN service router itself) wouldn't seem that hard to do IMHO, rather tha= n > changing 100% of clients. That way IPv6 could get a head start, but only > when needed at some point in time of the migration, and only in some > networks that need this feature, but neither IPv4 nor IPv6 is delayed > once/if the IPv4 or IPv6 session is established. > > At least one leading manufacturer already seems to do a good job of coupl= ing > users/ user groups to IPv4/CGN services via user profiles, so that any CG= N > switch off won't have to be an all or nothing process for all users at on= ce. > They could also build in that (artificial) IPv4 SYN delay on one particul= ar > CGN profile, so you can switch over to IPv6 by groups/ batches of users > without changing the client at all. > > I recently did a complex disentanglement of interconnects where people > weren't really certain what residual traffic was still running and why. A= s a > last step, the only practical operational way forward was to really cut t= he > wire, and have a rapid-response team in place to restore any important > functionality when "important" people "peeped" to the help desk, whilst > "non-important" people were told to reconfigure their apps or find anothe= r > solution themselves. No technology can tell you in advance of a cut off w= ith > 100% certainty what traffic is "important", or why it's still running. > People and processes are a far better solution to this type of problem. > > regards, > RayH > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From v6ops@globis.net Mon Jun 20 13:02:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96111F0C69 for ; Mon, 20 Jun 2011 13:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3w9UigqvBvnq for ; Mon, 20 Jun 2011 13:02:00 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4A81F0C38 for ; Mon, 20 Jun 2011 13:01:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D9B908700F0; Mon, 20 Jun 2011 22:01:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMlYY+KWwlR7; Mon, 20 Jun 2011 22:01:50 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C0985870030; Mon, 20 Jun 2011 22:01:50 +0200 (CEST) Message-ID: <4DFFA72E.3080605@globis.net> Date: Mon, 20 Jun 2011 22:01:50 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Cameron Byrne References: <4DFF7876.8050306@globis.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070500080906000705010606" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 20:02:00 -0000 This is a multi-part message in MIME format. --------------070500080906000705010606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for the reply Cameron Byrne wrote: > >> IMVHO If network operators want to turn off IPv4/CGN later in a controlled >> manner, they can achieve the effect of discouraging the use of IPv4/CGN >> compared to IPv6 by introducing some delay or configuration in their own >> particular CGN box / IPv4 service at a time and in a manner that suits their >> > > This is very unlikely that an SP would inject latency like this. In > fact, it is completely unrealistic from a business and instrumentation > perspective. > > I agree. My suggestion is only meant as a tool for those people who have expressed a requirement to be able to force behavior of the client to prefer one AF family over another (e.g. during phase out of CGN). Standard behavior on the majority of networks and clients would be to choose the fastest session set up with no handicapping at all. If it is not acceptable for the SP to add any artificial latency within the network for IPv4 SYN packets to prefer IPv6 during migration, why would we think that adding any (artificial) latency in every single client on every single network (whether they use CGN or not) would be any more acceptable? [current Chrome behavior?] Or indeed waiting for one AF family session to fail completely before trying another? [most current browsers] > > Generally, i like e2e solutions, not middle box manipulation. > > And CGN isn't middle box manipulation? ;) The IPv4 SYN packets may anyway need special treatment (to form a new NAT association in the CGN box) so I don't see this as being too onerous IMVHO. regards, RayH --------------070500080906000705010606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for the reply

Cameron Byrne wrote: 

IMVHO If network operators want to turn off IPv4/CGN later in a controlled
manner, they can achieve the effect of discouraging the use of IPv4/CGN
compared to IPv6 by introducing some delay or configuration in their own
particular CGN box / IPv4 service at a time and in a manner that suits their
    

This is very unlikely that an SP would inject latency like this.  In
fact, it is completely unrealistic from a business and instrumentation
perspective.
I agree. My suggestion is only meant as a tool for those people who have expressed a requirement to be able to force behavior of the client to prefer one AF family over another (e.g. during phase out of CGN).

Standard behavior on the majority of networks and clients would be to choose the fastest session set up with no handicapping at all.

If it is not acceptable for the SP to add any artificial latency within the network for IPv4 SYN packets to prefer IPv6 during migration, why would we think that adding any (artificial) latency in every single client on every single network (whether they use CGN or not) would be any more acceptable? [current Chrome behavior?]

Or indeed waiting for one AF family session to fail completely before trying another? [most current browsers]

<snip>
Generally, i like e2e solutions, not middle box manipulation.
And CGN isn't middle box manipulation? ;)

The IPv4 SYN packets may anyway need special treatment (to form a new NAT association in the CGN box) so I don't see this as being too onerous IMVHO.

regards,
RayH
--------------070500080906000705010606-- From cb.list6@gmail.com Mon Jun 20 13:18:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BA41F0C6F for ; Mon, 20 Jun 2011 13:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUecDLvvdsy6 for ; Mon, 20 Jun 2011 13:18:05 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 274B91F0C38 for ; Mon, 20 Jun 2011 13:18:04 -0700 (PDT) Received: by wwe5 with SMTP id 5so1943251wwe.13 for ; Mon, 20 Jun 2011 13:18:04 -0700 (PDT) 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=R3XdAwLF6BtcMnO59r5wiLqbFX293yjXro65UbNaN2U=; b=QyoSBNzKohTPw8xMt0ZB1N8WKtvvrmnzsKTE6vG/JaCalpy5eSRk8RBa1svclJXRW1 k/HetN/E95DdbYS6gAw3M+fzfCfuRcOp7CD8S5sdtpXafz5ImVUnVgANjbIc3T18WODg tNlWnhQxmwENlNt9lQ8uFHV58Yf+S65M5mM/g= 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=HzElAFhll2mqbT1jdpbDO/jaw4M+hDfZppuNgD5FH4P+4CsABH6vHWLNDmM8aEhP76 AJHqEM+wwuDiujcDFVTVMtKkz2Hcq0p/cS+WU1W/B083YwX6ltuH0ODx6UYoNe5cFy87 P/+6qZ5Xl+GZ4R9xxN7XR9f7GE/cTLbz91QXA= MIME-Version: 1.0 Received: by 10.216.59.16 with SMTP id r16mr5429062wec.25.1308601083903; Mon, 20 Jun 2011 13:18:03 -0700 (PDT) Received: by 10.216.165.82 with HTTP; Mon, 20 Jun 2011 13:18:03 -0700 (PDT) In-Reply-To: <4DFFA72E.3080605@globis.net> References: <4DFF7876.8050306@globis.net> <4DFFA72E.3080605@globis.net> Date: Mon, 20 Jun 2011 13:18:03 -0700 Message-ID: From: Cameron Byrne To: Ray Hunter Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 20:18:06 -0000 On Mon, Jun 20, 2011 at 1:01 PM, Ray Hunter wrote: > Thanks for the reply > > Cameron Byrne wrote: > > IMVHO If network operators want to turn off IPv4/CGN later in a controlled > manner, they can achieve the effect of discouraging the use of IPv4/CGN > compared to IPv6 by introducing some delay or configuration in their own > particular CGN box / IPv4 service at a time and in a manner that suits their > > > This is very unlikely that an SP would inject latency like this. In > fact, it is completely unrealistic from a business and instrumentation > perspective. > > > > I agree. My suggestion is only meant as a tool for those people who have > expressed a requirement to be able to force behavior of the client to prefer > one AF family over another (e.g. during phase out of CGN). > > Standard behavior on the majority of networks and clients would be to choose > the fastest session set up with no handicapping at all. > Can you cite the standard you refer to? On my Windows and Linux systems, i seem to always go to the IPv6 / AAAA destination first, if it is available. > If it is not acceptable for the SP to add any artificial latency within the > network for IPv4 SYN packets to prefer IPv6 during migration, why would we > think that adding any (artificial) latency in every single client on every > single network (whether they use CGN or not) would be any more acceptable? > [current Chrome behavior?] > > Or indeed waiting for one AF family session to fail completely before trying > another? [most current browsers] > Does this contradict what you said about "standard behavior"? > > > Generally, i like e2e solutions, not middle box manipulation. > > > > And CGN isn't middle box manipulation? ;) > It is. The only way to get the flow off the middle box is for the end-point to initiate the flow on IPv6. The smarts should be in the end points, not the middle box. > The IPv4 SYN packets may anyway need special treatment (to form a new NAT > association in the CGN box) so I don't see this as being too onerous IMVHO. > > regards, > RayH > From v6ops@globis.net Mon Jun 20 14:30:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189FA11E8222 for ; Mon, 20 Jun 2011 14:30:11 -0700 (PDT) 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.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8mN7TsOQO-j for ; Mon, 20 Jun 2011 14:30:10 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3686D11E8213 for ; Mon, 20 Jun 2011 14:30:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id CC5BA8700E2; Mon, 20 Jun 2011 23:30:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wEwAvJlqy74; Mon, 20 Jun 2011 23:30:00 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 73C5D87007F; Mon, 20 Jun 2011 23:30:00 +0200 (CEST) Message-ID: <4DFFBBD8.9050301@globis.net> Date: Mon, 20 Jun 2011 23:30:00 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Cameron Byrne References: <4DFF7876.8050306@globis.net> <4DFFA72E.3080605@globis.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030003080806000300080202" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] simplfying Happy Eyeballs further X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 21:30:11 -0000 This is a multi-part message in MIME format. --------------030003080806000300080202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit "Standard" was perhaps an unfortunate choice of wording on my part. "Vanilla"? Cameron Byrne wrote: > On Mon, Jun 20, 2011 at 1:01 PM, Ray Hunter wrote: > >> Standard behavior on the majority of networks and clients would be to choose >> the fastest session set up with no handicapping at all. >> > Can you cite the standard you refer to? On my Windows and Linux > systems, i seem to always go to the IPv6 / AAAA destination first, if > it is available. > > See below. >> If it is not acceptable for the SP to add any artificial latency within the >> network for IPv4 SYN packets to prefer IPv6 during migration, why would we >> think that adding any (artificial) latency in every single client on every >> single network (whether they use CGN or not) would be any more acceptable? >> [current Chrome behavior?] >> >> Or indeed waiting for one AF family session to fail completely before trying >> another? [most current browsers] >> > Does this contradict what you said about "standard behavior"? > > Assuming "amended Happy Eyeballs" becomes a standard address selection algorithm based on a simple straight race with a cached result, as I suggested. RFC 3484 (and RFC 3484 bis) are also standard address selection algorithms. I see no contradiction personally. Address selection algorithms to me are an application level choice. They do not have to preclude each other, even though all are "standard." If a developer chooses to implement "amended Happy Eyeballs" (and no RFC3484) then the browser app would start two sessions in parallel for the first IPv4 and first IPv6 returned by DNS (if there was no cached entry), and use the first one to complete the SYN ACK handshake in a straight race. Once the cache is filled there'd be no need to start two sessions. The cache would flush regularly, and also on interface changes. This is for me the easiest vanilla form to implement and is just a simplified version of the current Happy Eyeballs draft (with IH =0 and no handicapping algorithm). If a developer chooses to implement just RFC3484, then the app could try one session to the first entry in the orderd list from the source / destination address selection process. If that session fails it starts a second session to the second entry and so on. [most current browsers] But I don't read anything fundamental in RFC3484 that would stop a developer from treating the result of the address selection rules as an ordered list, to be manipulated further, rather than an absolute selection. If a developer chooses to implement both RFC 3484 and amended Happy Eyeballs, the app can still select "the best" IPv6 and "the best" IPv4 (from RFC3484) and kick two sessions off in parallel for IPv4 and IPv6 in a race with no initial delay. The app can then wait as long as the developer likes for both sessions to complete (implementation dependent). If only one session completes in a time acceptable for this application, job done, and the cache can be filled. If both session start ups complete within an acceptable time of each other then the developer can still use the list ordering from RFC3484 in any tie break for selecting the appropriate address family. I personally see this as minor difference to Chrome (perhaps a few more SYN packets until a cached entry is learned). I also think it's relatively simple, whilst still giving system/network managers a chance of influencing choice of AF via the existing RFC3484 mechanism, rather than any external timers/ additional config. Others may disagree. Perhaps I'm being dumb and have missed something in the text that you have seen. >> >> >> Generally, i like e2e solutions, not middle box manipulation. >> >> >> >> And CGN isn't middle box manipulation? ;) >> >> > > It is. The only way to get the flow off the middle box is for the > end-point to initiate the flow on IPv6. The smarts should be in the > end points, not the middle box. I humbly disagree that it's the "only way." --------------030003080806000300080202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit  "Standard" was perhaps an unfortunate choice of wording on my part. "Vanilla"?

Cameron Byrne wrote: 
On Mon, Jun 20, 2011 at 1:01 PM, Ray Hunter <v6ops@globis.net> wrote:
  
Standard behavior on the majority of networks and clients would be to choose
the fastest session set up with no handicapping at all.
    
Can you cite the standard you refer to? On my Windows and Linux
systems, i seem to always go to the IPv6 / AAAA destination first, if
it is available.
See below.

  

    
If it is not acceptable for the SP to add any artificial latency within the
network for IPv4 SYN packets to prefer IPv6 during migration, why would we
think that adding any (artificial) latency in every single client on every
single network (whether they use CGN or not) would be any more acceptable?
[current Chrome behavior?]

Or indeed waiting for one AF family session to fail completely before trying
another? [most current browsers]
    

  

  
Does this contradict what you said about "standard behavior"?

  



Assuming "amended Happy Eyeballs" becomes a standard address selection
algorithm based on a simple straight race with a cached result, as I
suggested.



RFC 3484 (and RFC 3484 bis) are also standard address selection
algorithms.



I see no contradiction personally. Address selection algorithms to me
are an application level choice. They do not have to preclude each
other, even though all are "standard."



If a developer chooses to implement "amended Happy Eyeballs" (and no
RFC3484) then the browser app would start two sessions in parallel for
the first IPv4 and first IPv6 returned by DNS (if there was no cached
entry), and use the first one to complete the SYN ACK handshake in a
straight race. Once the cache is filled there'd be no need to start two
sessions. The cache would flush regularly, and also on interface
changes. This is for me the easiest vanilla form to implement and is
just a simplified version of the current Happy Eyeballs draft (with IH
=0 and no handicapping algorithm).



If a developer chooses to implement just RFC3484, then the app could
try one
session to the first entry in the orderd list from the source /
destination
address selection process. If that session fails it starts a second
session to the second entry and so on. [most current browsers]



But I don't read anything fundamental in RFC3484 that would stop a
developer from treating the result of the address selection rules as an
ordered list, to be manipulated further, rather than an absolute
selection.



If a developer chooses to implement both RFC 3484 and amended Happy
Eyeballs, the app can still select "the best" IPv6 and "the best" IPv4
(from RFC3484) and kick two sessions off in parallel for IPv4 and IPv6
in a race with no initial delay. The app can then wait as long as the
developer likes for both sessions to complete (implementation
dependent). If only one session completes in a time acceptable for this
application, job done, and the cache can be filled. If both session
start ups complete within an acceptable time of each other then the
developer can still use the list ordering from RFC3484 in any tie break
for selecting the appropriate address family. I personally see this as
minor difference to Chrome (perhaps a few more SYN packets until a
cached entry is learned). I also think it's relatively simple, whilst
still giving system/network managers a chance of influencing choice of
AF via the existing RFC3484 mechanism, rather than any external timers/
additional config. Others may disagree.



Perhaps I'm being dumb and have missed something in the text that you
have seen.



  

  

    
<snip>

Generally, i like e2e solutions, not middle box manipulation.



And CGN isn't middle box manipulation? ;)

    

  

  

It is. The only way to get the flow off the middle box is for the
end-point to initiate the flow on IPv6.  The smarts should be in the
end points, not the middle box.



I humbly disagree that it's the "only way."




--------------030003080806000300080202--

From Fred.L.Templin@boeing.com  Mon Jun 20 16:35:06 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B64111E81FD for ; Mon, 20 Jun 2011 16:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.427
X-Spam-Level: 
X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.171,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZaaisThp1o6 for ; Mon, 20 Jun 2011 16:35:05 -0700 (PDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 274BC11E81FA for ; Mon, 20 Jun 2011 16:35:05 -0700 (PDT)
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 p5KNYpIW002552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Jun 2011 18:34:56 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p5KNYoNM006601; Mon, 20 Jun 2011 16:34:50 -0700 (PDT)
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 p5KNYiMu006512 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 20 Jun 2011 16:34:44 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 20 Jun 2011 16:34:44 -0700
From: "Templin, Fred L" 
To: Ray Hunter , Cameron Byrne 
Date: Mon, 20 Jun 2011 16:34:42 -0700
Thread-Topic: [v6ops] simplfying Happy Eyeballs further
Thread-Index: AcwvkYYHZa7cfJpEQDu5CCMa27+iIQAEI1og
Message-ID: 
References: <4DFF7876.8050306@globis.net>  <4DFFA72E.3080605@globis.net>  <4DFFBBD8.9050301@globis.net>
In-Reply-To: <4DFFBBD8.9050301@globis.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A65C6A89E458XCHNW01Vnwnos_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jun 2011 23:35:06 -0000

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

I think I'm with Ray and the others who liked the idea of a straight
race when both IPv4 and IPv6 addresses are available.

Thanks - Fred
fred.l.templin@boeing.com

________________________________
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of R=
ay Hunter
Sent: Monday, June 20, 2011 2:30 PM
To: Cameron Byrne
Cc: v6ops@ietf.org WG
Subject: Re: [v6ops] simplfying Happy Eyeballs further

 "Standard" was perhaps an unfortunate choice of wording on my part. "Vanil=
la"?

Cameron Byrne wrote:

On Mon, Jun 20, 2011 at 1:01 PM, Ray Hunter  wrote:


Standard behavior on the majority of networks and clients would be to choos=
e
the fastest session set up with no handicapping at all.


Can you cite the standard you refer to? On my Windows and Linux
systems, i seem to always go to the IPv6 / AAAA destination first, if
it is available.



See below.

If it is not acceptable for the SP to add any artificial latency within the
network for IPv4 SYN packets to prefer IPv6 during migration, why would we
think that adding any (artificial) latency in every single client on every
single network (whether they use CGN or not) would be any more acceptable?
[current Chrome behavior?]

Or indeed waiting for one AF family session to fail completely before tryin=
g
another? [most current browsers]


Does this contradict what you said about "standard behavior"?



Assuming "amended Happy Eyeballs" becomes a standard address selection algo=
rithm based on a simple straight race with a cached result, as I suggested.

RFC 3484 (and RFC 3484 bis) are also standard address selection algorithms.

I see no contradiction personally. Address selection algorithms to me are a=
n application level choice. They do not have to preclude each other, even t=
hough all are "standard."

If a developer chooses to implement "amended Happy Eyeballs" (and no RFC348=
4) then the browser app would start two sessions in parallel for the first =
IPv4 and first IPv6 returned by DNS (if there was no cached entry), and use=
 the first one to complete the SYN ACK handshake in a straight race. Once t=
he cache is filled there'd be no need to start two sessions. The cache woul=
d flush regularly, and also on interface changes. This is for me the easies=
t vanilla form to implement and is just a simplified version of the current=
 Happy Eyeballs draft (with IH =3D0 and no handicapping algorithm).

If a developer chooses to implement just RFC3484, then the app could try on=
e session to the first entry in the orderd list from the source / destinati=
on address selection process. If that session fails it starts a second sess=
ion to the second entry and so on. [most current browsers]

But I don't read anything fundamental in RFC3484 that would stop a develope=
r from treating the result of the address selection rules as an ordered lis=
t, to be manipulated further, rather than an absolute selection.

If a developer chooses to implement both RFC 3484 and amended Happy Eyeball=
s, the app can still select "the best" IPv6 and "the best" IPv4 (from RFC34=
84) and kick two sessions off in parallel for IPv4 and IPv6 in a race with =
no initial delay. The app can then wait as long as the developer likes for =
both sessions to complete (implementation dependent). If only one session c=
ompletes in a time acceptable for this application, job done, and the cache=
 can be filled. If both session start ups complete within an acceptable tim=
e of each other then the developer can still use the list ordering from RFC=
3484 in any tie break for selecting the appropriate address family. I perso=
nally see this as minor difference to Chrome (perhaps a few more SYN packet=
s until a cached entry is learned). I also think it's relatively simple, wh=
ilst still giving system/network managers a chance of influencing choice of=
 AF via the existing RFC3484 mechanism, rather than any external timers/ ad=
ditional config. Others may disagree.

Perhaps I'm being dumb and have missed something in the text that you have =
seen.



Generally, i like e2e solutions, not middle box manipulation.



And CGN isn't middle box manipulation? ;)




It is. The only way to get the flow off the middle box is for the
end-point to initiate the flow on IPv6.  The smarts should be in the
end points, not the middle box.

I humbly disagree that it's the "only way."

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







I=20
think I'm with Ray and the others who liked the idea of a=20
straight


race when both IPv4 and IPv6 addresses are available.


 


Thanks - Fred


fred.l.templin@boeing.com



  

  

  From: v6ops-bounces@ietf.org=20
  [mailto:v6ops-bounces@ietf.org] On Behalf Of Ray Hunter
Sent=
:=20
  Monday, June 20, 2011 2:30 PM
To: Cameron Byrne
Cc:=20
  v6ops@ietf.org WG
Subject: Re: [v6ops] simplfying Happy Eyeball=
s=20
  further


  
 "Standard" was perhaps an unfortunate choice of wording =
on my=20
  part. "Vanilla"?

Cameron Byrne wrote:=20
  
On Mon, Jun 20, 2011 at 1:01 PM, Ray Hunter =
<v6ops=
@globis.net> wrote:
  

    
Standard behavior on the major=
ity of networks and clients would be to choose
the fastest session set up with no handicapping at all.
    
Can you cite the standard you refer t=
o? On my Windows and Linux
systems, i seem to always go to the IPv6 / AAAA destination first, if
it is available.

  
See below.

  

    
If it is not acceptable for th=
e SP to add any artificial latency within the
network for IPv4 SYN packets to prefer IPv6 during migration, why would we
think that adding any (artificial) latency in every single client on every
single network (whether they use CGN or not) would be any more acceptable?
[current Chrome behavior?]

Or indeed waiting for one AF family session to fail completely before tryin=
g
another? [most current browsers]
    
Does this contradict what you said ab=
out "standard behavior"?

  
Assuming "amended Happy Eyeballs" becomes a standard=20
  address selection algorithm based on a simple straight race wit=
h a=20
  cached result, as I suggested.

RFC 3484 (and RFC 3484 bis) are=20
  also standard address selection algorithms.

I see no contradi=
ction=20
  personally. Address selection algorithms to me are an application level=20
  choice. They do not have to preclude each other, even though all are=20
  "standard."

If a developer chooses to implement "amended Happ=
y=20
  Eyeballs" (and no RFC3484) then the browser app would start two sessions =
in=20
  parallel for the first IPv4 and first IPv6 returned by DNS (if there was =
no=20
  cached entry), and use the first one to complete the SYN ACK handshake in=
 a=20
  straight race. Once the cache is filled there'd be no need to start two=20
  sessions. The cache would flush regularly, and also on interface changes.=
 This=20
  is for me the easiest vanilla form to implement and is just a simpli=
fied=20
  version of the current Happy Eyeballs draft (with IH =3D0 and no handicap=
ping=20
  algorithm).

If a developer chooses to implement just RFC3484, then=
 the=20
  app could try one session to the first entry in the orderd list from the=
=20
  source / destination address selection process. If that session fails it=
=20
  starts a second session to the second entry and so on. [most current=20
  browsers]

But I don't read anything fundamental in RFC3484 that wo=
uld=20
  stop a developer from treating the result of the address selection rules =
as an=20
  ordered list, to be manipulated further, rather than an absolute=20
  selection.

If a developer chooses to implement both RFC 3484 =
and=20
  amended Happy Eyeballs, the app can still select "the best" IPv6 and "the=
=20
  best" IPv4 (from RFC3484) and kick two sessions off in parallel for IPv4 =
and=20
  IPv6 in a race with no initial delay. The app can then wait as long as th=
e=20
  developer likes for both sessions to complete (implementation dependent).=
 If=20
  only one session completes in a time acceptable for this application, job=
=20
  done, and the cache can be filled. If both session start ups complet=
e=20
  within an acceptable time of each other then the developer can still use =
the=20
  list ordering from RFC3484 in any tie break for selecting the approp=
riate=20
  address family. I personally see this as minor difference to Chrome (perh=
aps a=20
  few more SYN packets until a cached entry is learned). I also think it's=
=20
  relatively simple, whilst still giving system/network managers a chance o=
f=20
  influencing choice of AF via the existing RFC3484 mechanism, rather than =
any=20
  external timers/ additional config. Others may disagree.

Perhaps I=
'm=20
  being dumb and have missed something in the text that you have seen.

  

    
<snip>

Generally, i like e2e solutions, not middle box manipulation.



And CGN isn't middle box manipulation? ;)

    

It is. The only way to get the flow off the middle box is for the
end-point to initiate the flow on IPv6.  The smarts should be in the
end points, not the middle box.
I humbly disagree that it=
's=20
  the "only way."


--_000_E1829B60731D1740BB7A0626B4FAF0A65C6A89E458XCHNW01Vnwnos_--


From marka@isc.org  Mon Jun 20 18:06:38 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E837311E8071 for ; Mon, 20 Jun 2011 18:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.392
X-Spam-Level: 
X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-5QRMs0rDxc for ; Mon, 20 Jun 2011 18:06:38 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8C011E80C8 for ; Mon, 20 Jun 2011 18:06:38 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 139E1C944E; Tue, 21 Jun 2011 01:06:26 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id A6239216C7B; Tue, 21 Jun 2011 01:06:25 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 03CB410F29A0; Tue, 21 Jun 2011 11:06:23 +1000 (EST)
To: "Templin, Fred L" 
From: Mark Andrews 
References: <4DFF7876.8050306@globis.net>  <4DFFA72E.3080605@globis.net>  <4DFFBBD8.9050301@globis.net> 
In-reply-to: Your message of "Mon, 20 Jun 2011 16:34:42 MST." 
Date: Tue, 21 Jun 2011 11:06:22 +1000
Message-Id: <20110621010623.03CB410F29A0@drugs.dv.isc.org>
Cc: Ray Hunter , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 01:06:39 -0000

In message , "Templin, Fred L" writes:
> I think I'm with Ray and the others who liked the idea of a straight
> race when both IPv4 and IPv6 addresses are available.

If CGN added enough delay to make IPv4 slower I might agree with
you but they won't.  Additionally race to win always results in
redundant connection being made in a correctly working network which
is totally unneeded.

HE needs to work well enough with a broken IPv6 network and not
cause problems with a working IPv6 network.  This working group
seems to be too focused on making a broken network work well verses
not making a working network worse.

Applications supporting HE will be in use long after the need for
HE to address large scale IPv6 brokenness has gone and the failure
mode is "this address is unreachable" rather than "IPv6 is unreachable"
and all addresses are reachable 99.999% of the time.

Let getaddrinfo() do its job and sort the addresses.  Try them in
the order returned with a short timeout.  Re-use the working address
if you need to re-connect to the same host.  This will give you
reasonable performance with a broken/tunneled IPv6 or broken/tunneled
IPv4 network and good performance with when both stacks are working.

If we don't let getaddrinfo() do its job and sort the addresses
there will be complaints that the applications don't honour the
address selection rules in a few years time.

Mark

> Thanks - Fred
> fred.l.templin@boeing.com
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From newbery@gmail.com  Mon Jun 20 19:57:39 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0177A11E80A0 for ; Mon, 20 Jun 2011 19:57:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.299,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM-M8fnWBTOx for ; Mon, 20 Jun 2011 19:57:36 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 31C8B11E809E for ; Mon, 20 Jun 2011 19:57:36 -0700 (PDT)
Received: by qwc23 with SMTP id 23so1799479qwc.31 for ; Mon, 20 Jun 2011 19:57:35 -0700 (PDT)
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=XvEqHrgs0om5EhwhBKhSzvlhQ6CTsLTKuBCg3yJJiXQ=; b=VUQ7RWbbQAvPprv2d9wD8tK27olPDzQivVLywXXVGotzXs4AaNRMgYmysQk4JAxHg6 BaBqb6ZMGxCUgagFe7H9ktvB+DlsQLbFVPQup1XMFDJ3C417HhZJjQWBUJIMGdGnez8g LYeO+ynt3prHKmnX/l4he9Boxl7B6ISICrZxY=
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=Ll3xyzRmpGU/WvTF872oN+qf8x0ORvO0H9A/uztM2A7D804WuV6iDpP5bnKxQAn34f sSZDqKE1ADISA4FkkgoFAZaghBFyrA4dX5F/MNxE5QaoJ46b0rdL25tiWYZSsnf+Nnvz /fdZXZU6L1TxY5Nw1qJDy7ut6tmjj9MAtS/CY=
Received: by 10.224.183.204 with SMTP id ch12mr3274264qab.341.1308625055434; Mon, 20 Jun 2011 19:57:35 -0700 (PDT)
Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id p10sm4619313qcu.37.2011.06.20.19.57.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2011 19:57:34 -0700 (PDT)
From: Michael Newbery 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-3--394631805; protocol="application/pkcs7-signature"; micalg=sha1
Date: Tue, 21 Jun 2011 14:57:25 +1200
In-Reply-To: 
To: "v6ops@ietf.org WG" 
References: <007101cc2d4e$473e8380$d5bb8a80$@com> <4DFCADEA.4080100@gmail.com> 
Message-Id: 
X-Mailer: Apple Mail (2.1084)
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 02:57:39 -0000

--Apple-Mail-3--394631805
Content-Type: multipart/alternative;
	boundary=Apple-Mail-2--394635902


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


On 19/06/2011, at 2:46 AM, Cameron Byrne wrote:

>=20
> On Jun 18, 2011 6:54 AM, "Brian E Carpenter" =
 wrote:
> >
> > I prefer
> >
> > > a. initiate two simultaneous connection attempts
> >
> > or even three. Some studies we've done on SHIM6/REAP and MPTCP =
performance
> > suggest that probing up to 3 addresses in parallel doesn't create
> > a significant load but does improve the time to establish a =
connection.
> >
>=20
> Just like cell phones that constantly turn off and on their data =
connections to optimize battery life, but in turn wreck the network with =
a flood of signalling to attach and detach.
>=20
> Please no.
>=20
> Some of us are thinking about cgn exit strategies, and these ipv4 =
connections will be enough noise that I cannot properly dimension the =
ramp down.
>=20
> Sorry, we cannot always engineer the system to optimize on just the =
user experience and expect all the other elements to scale and perform =
well. I know there may be some backoff mechanism and affinity, but this =
is a slippery slope where implementers will look to "improve " on a good =
idea to make their product look better. I do not look forward to my HE =
refrigerator sending out simultaneous connections to upload my grocery =
list to the cloud.
>=20

Given that Google Maps and iTunes already attempt 150+ simultaneous =
connections, does three rather than two happy-eyballs attempts really =
matter?=20

Actually, thinking about it, this presents an interesting problem to =
happy eyeballs. Since most modern browsers attempt to parallelise =
requests, and many of these parallel requests are to the same IP =
address, what is the best approach? Should the browser attempt a SINGLE =
happy eyeballs connection attempt, PER HOST, and then go parallel once =
the connection result is known; or should it launch happy eyeballs =
simultaneously on every session.

The former strategy negates some of the user benefits, as the bulk of =
the parallel transfers are delayed while they first session connection =
per host is established; the second makes for an, arguably, overly =
chatty host (and upsets LSNs---which some might consider an upside :) ). =
The former could be tricky to code; the latter may be resource heavy for =
things like smart phones.=

--Apple-Mail-2--394635902
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii




On Jun 18, 2011 6:54 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:

>

> I prefer

>

> > a. initiate two simultaneous connection attempts

>

> or even three. Some studies we've done on SHIM6/REAP and MPTCP =
performance

> suggest that probing up to 3 addresses in parallel doesn't =
create

> a significant load but does improve the time to establish a =
connection.

>
Just like cell phones that constantly turn off and on their =
data connections to optimize battery life, but in turn wreck the network =
with a flood of signalling to attach and detach. 
Please =
no.
Some of us are thinking about cgn exit strategies, and these =
ipv4 connections will be enough noise that I cannot properly dimension =
the ramp down.
Sorry, we cannot always engineer the system to =
optimize on just the user experience and expect all the other elements =
to scale and perform well. I know there may be some backoff mechanism =
and affinity, but this is a slippery slope where implementers will look =
to "improve " on a good idea to make their product look better. I do not =
look forward to my HE refrigerator sending out simultaneous connections =
to upload my grocery list to the cloud. =


Given that Google Maps and iTunes =
already attempt 150+ simultaneous connections, does three rather than =
two happy-eyballs attempts really =
matter? 

Actually, thinking about it, this =
presents an interesting problem to happy eyeballs. Since most modern =
browsers attempt to parallelise requests, and many of these parallel =
requests are to the same IP address, what is the best approach? Should =
the browser attempt a SINGLE happy eyeballs connection attempt, PER =
HOST, and then go parallel once the connection result is known; or =
should it launch happy eyeballs simultaneously on every =
session.

The former strategy negates some of =
the user benefits, as the bulk of the parallel transfers are delayed =
while they first session connection per host is established; the second =
makes for an, arguably, overly chatty host (and upsets LSNs---which some =
might consider an upside :) ). The former could be tricky to code; the =
latter may be resource heavy for things like smart =
phones.
=

--Apple-Mail-2--394635902--

--Apple-Mail-3--394631805
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
AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwNjIxMDI1NzMw
WjAjBgkqhkiG9w0BCQQxFgQU/EWYtXXNpSjFQk4hE/SFH6IOB5gwgZEGCSsGAQQBgjcQBDGBgzCB
gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg
BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA
Y2FjZXJ0Lm9yZwIDCbnFMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB
MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCbnFMA0GCSqG
SIb3DQEBAQUABIIBAKqoEWApIyva49NPGaJgJBKFLpT2v1zkAajXA7xAk2oS/kLiJ+ewSsbUCTeP
dT6oNz6Nc8p1cAuvrKcZ/TDQJsRdEOAaJOSuZGANhSJacFioAgcUSV1Pz/PKlZsyyrV0zaQ48rS4
tHBaezVTWRQx1pAZdnYtFQlB5I3akbsj0Sr0J3auexIIATdvOvSx/8qMrdSXIxi7tdHu7P6DxLhw
kp/pgkHIEaJhQYsri1H6swcIXhJfw0fZBLpIsSVJZ7PMTFkX6iM/yU0CxwnzeB+sXh9tRR0E3WOm
tfWRqDFX2cfsCnmD8pUetjFkaEJnW8wMe/Ogoe4pp0YqqQQ4Op5YMrYAAAAAAAA=

--Apple-Mail-3--394631805--

From joelja@bogus.com  Mon Jun 20 20:47:28 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C6711E8147 for ; Mon, 20 Jun 2011 20:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.742
X-Spam-Level: 
X-Spam-Status: No, score=-101.742 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB6pkTzOyZg9 for ; Mon, 20 Jun 2011 20:47:27 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D4D6011E80DB for ; Mon, 20 Jun 2011 20:47:26 -0700 (PDT)
Received: from [192.168.1.171] (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 p5L3lJNS096710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 21 Jun 2011 03:47:19 GMT (envelope-from joelja@bogus.com)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-2--391643361
From: Joel Jaeggli 
In-Reply-To: 
Date: Mon, 20 Jun 2011 20:47:18 -0700
Message-Id: 
References: <007101cc2d4e$473e8380$d5bb8a80$@com> <4DFCADEA.4080100@gmail.com>  
To: Michael Newbery 
X-Mailer: Apple Mail (2.1084)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 21 Jun 2011 03:47:22 +0000 (UTC)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 03:47:28 -0000

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


On Jun 20, 2011, at 7:57 PM, Michael Newbery wrote:

>=20
> On 19/06/2011, at 2:46 AM, Cameron Byrne wrote:
>=20
>>=20
>> On Jun 18, 2011 6:54 AM, "Brian E Carpenter" =
 wrote:
>> >
>> > I prefer
>> >
>> > > a. initiate two simultaneous connection attempts
>> >
>> > or even three. Some studies we've done on SHIM6/REAP and MPTCP =
performance
>> > suggest that probing up to 3 addresses in parallel doesn't create
>> > a significant load but does improve the time to establish a =
connection.
>> >
>>=20
>> Just like cell phones that constantly turn off and on their data =
connections to optimize battery life, but in turn wreck the network with =
a flood of signalling to attach and detach.
>>=20
>> Please no.
>>=20
>> Some of us are thinking about cgn exit strategies, and these ipv4 =
connections will be enough noise that I cannot properly dimension the =
ramp down.
>>=20
>> Sorry, we cannot always engineer the system to optimize on just the =
user experience and expect all the other elements to scale and perform =
well. I know there may be some backoff mechanism and affinity, but this =
is a slippery slope where implementers will look to "improve " on a good =
idea to make their product look better. I do not look forward to my HE =
refrigerator sending out simultaneous connections to upload my grocery =
list to the cloud.
>>=20
>=20
> Given that Google Maps and iTunes already attempt 150+ simultaneous =
connections, does three rather than two happy-eyballs attempts really =
matter?=20
>=20
> Actually, thinking about it, this presents an interesting problem to =
happy eyeballs. Since most modern browsers attempt to parallelise =
requests, and many of these parallel requests are to the same IP =
address, what is the best approach? Should the browser attempt a SINGLE =
happy eyeballs connection attempt, PER HOST, and then go parallel once =
the connection result is known; or should it launch happy eyeballs =
simultaneously on every session.

A modern desktop pc can as a server, maintain thousands of simultaneous =
tcp connections without much effort. the $49.95 nat box you bought with =
16MB of ram not so much, the $.5 million dollar firewall cluster someone =
might deploy to do LSN has a distinct incentive to minimize the number =
of connections per user... In some sense the ability to reap some =
connections quickly is nice but stateful inspection devices are limited =
by the number of new connections per second as well as the size of the =
total number of connections.

> The former strategy negates some of the user benefits, as the bulk of =
the parallel transfers are delayed while they first session connection =
per host is established; the second makes for an, arguably, overly =
chatty host (and upsets LSNs---which some might consider an upside :) ). =
The former could be tricky to code; the latter may be resource heavy for =
things like smart phones.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


--Apple-Mail-2--391643361
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On =
19/06/2011, at 2:46 AM, Cameron Byrne wrote:



On Jun 18, 2011 6:54 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:

>

> I prefer

>

> > a. initiate two simultaneous connection attempts

>

> or even three. Some studies we've done on SHIM6/REAP and MPTCP =
performance

> suggest that probing up to 3 addresses in parallel doesn't =
create

> a significant load but does improve the time to establish a =
connection.

>
Just like cell phones that constantly turn off and on their =
data connections to optimize battery life, but in turn wreck the network =
with a flood of signalling to attach and detach. 
Please =
no.
Some of us are thinking about cgn exit strategies, and these =
ipv4 connections will be enough noise that I cannot properly dimension =
the ramp down.
Sorry, we cannot always engineer the system to =
optimize on just the user experience and expect all the other elements =
to scale and perform well. I know there may be some backoff mechanism =
and affinity, but this is a slippery slope where implementers will look =
to "improve " on a good idea to make their product look better. I do not =
look forward to my HE refrigerator sending out simultaneous connections =
to upload my grocery list to the cloud. =





The former strategy negates some of the user =
benefits, as the bulk of the parallel transfers are delayed while they =
first session connection per host is established; the second makes for =
an, arguably, overly chatty host (and upsets LSNs---which some might =
consider an upside :) ). The former could be tricky to code; the latter =
may be resource heavy for things like smart =
phones.
_______________________________________________
v6op=
s mailing list
v6ops@ietf.org
https://www.ietf.org/=
mailman/listinfo/v6ops

=

--Apple-Mail-2--391643361--

From pch-b2B3A6689@u-1.phicoh.com  Tue Jun 21 01:22:19 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA2011E80DA for ; Tue, 21 Jun 2011 01:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.479
X-Spam-Level: 
X-Spam-Status: No, score=-8.479 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZXYXnI2ISCL for ; Tue, 21 Jun 2011 01:22:18 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1F89011E80BC for ; Tue, 21 Jun 2011 01:22:17 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QYwDu-0001MXC; Tue, 21 Jun 2011 10:22:14 +0200
Message-Id: 
To: Mark Andrews 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References: <4DFF7876.8050306@globis.net>  <4DFFA72E.3080605@globis.net>  <4DFFBBD8.9050301@globis.net>  <20110621010623.03CB410F29A0@drugs.dv.isc.org> 
In-reply-to: Your message of "Tue, 21 Jun 2011 11:06:22 +1000 ." <20110621010623.03CB410F29A0@drugs.dv.isc.org> 
Date: Tue, 21 Jun 2011 10:22:01 +0200
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 08:22:19 -0000

In your letter dated Tue, 21 Jun 2011 11:06:22 +1000 you wrote:
>If CGN added enough delay to make IPv4 slower I might agree with
>you but they won't.  Additionally race to win always results in
>redundant connection being made in a correctly working network which
>is totally unneeded.

How can you be so sure that CGN doesn't add any delays? If CGN is perfect from
a performance point of view, then there is no (performance) reason to try IPv6
at all.

I'm not so sure that all ISPs will be able to afford buying CGN capacity for
peak load. 

I agree that just letting IPv4 and IPv6 connection race is not the right way
to do things. 

>HE needs to work well enough with a broken IPv6 network and not
>cause problems with a working IPv6 network.  This working group
>seems to be too focused on making a broken network work well verses
>not making a working network worse.

Yes. It may be able to do more. But this should be the core functionality.

>Applications supporting HE will be in use long after the need for
>HE to address large scale IPv6 brokenness has gone and the failure
>mode is "this address is unreachable" rather than "IPv6 is unreachable"
>and all addresses are reachable 99.999% of the time.

I think both are needed. A dual stack server may have a problem with IPv6, so
it would be good to avoid connecting over IPv6 to that server. But locally, 
there may also be a failure that affects just IPv6. 

>Let getaddrinfo() do its job and sort the addresses.  Try them in
>the order returned with a short timeout.  Re-use the working address
>if you need to re-connect to the same host.  This will give you
>reasonable performance with a broken/tunneled IPv6 or broken/tunneled
>IPv4 network and good performance with when both stacks are working.
>
>If we don't let getaddrinfo() do its job and sort the addresses
>there will be complaints that the applications don't honour the
>address selection rules in a few years time.

I don't care at all about the default policy table. I don't see why HE would
have to respect that.

It would be different if an admin specifically installs a different policy
table. So (at least conceptually) we may need some flags in the getaddrinfo 
result that specify whether HE should be active at all or whether it is allowed
to reorder addresses.



From pch-b2B3A6689@u-1.phicoh.com  Tue Jun 21 01:33:10 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C74C9E800D for ; Tue, 21 Jun 2011 01:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.499
X-Spam-Level: 
X-Spam-Status: No, score=-8.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FMI00DHBkfY for ; Tue, 21 Jun 2011 01:33:09 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCF09E800B for ; Tue, 21 Jun 2011 01:33:08 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QYwOO-0001hHC; Tue, 21 Jun 2011 10:33:04 +0200
Message-Id: 
To: Michael Newbery 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References: <007101cc2d4e$473e8380$d5bb8a80$@com> <4DFCADEA.4080100@gmail.com>   
In-reply-to: Your message of "Tue, 21 Jun 2011 14:57:25 +1200 ."  
Date: Tue, 21 Jun 2011 10:33:03 +0200
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 08:33:10 -0000

In your letter dated Tue, 21 Jun 2011 14:57:25 +1200 you wrote:
>Actually, thinking about it, this presents an interesting problem to 
>happy eyeballs. Since most modern browsers attempt to parallelise 
>requests, and many of these parallel requests are to the same IP 
>address, what is the best approach? Should the browser attempt a SINGLE 
>happy eyeballs connection attempt, PER HOST, and then go parallel once 
>the connection result is known; or should it launch happy eyeballs 
>simultaneously on every session.

I don't think this is a big problem. HE keeps track of how long it normally
takes to set up a connection. There will be no extra overhead as long as the
timeout is long enough that most connects succeed within the timeout. So
it is only particularly far or slow servers that cause extra connections to
be set up.

This may have an impact on already overloaded servers. So the
'slashdot effect' may get worse.



From marka@isc.org  Tue Jun 21 05:02:48 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99CB11E80DF for ; Tue, 21 Jun 2011 05:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.41
X-Spam-Level: 
X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[AWL=1.189,  BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAkMo1W0gkUa for ; Tue, 21 Jun 2011 05:02:47 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 9896E11E80C2 for ; Tue, 21 Jun 2011 05:02:46 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 7A175C94D5; Tue, 21 Jun 2011 12:02:32 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0C797216C81; Tue, 21 Jun 2011 12:02:32 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id DA6C610FB5AE; Tue, 21 Jun 2011 22:02:29 +1000 (EST)
To: Philip Homburg 
From: Mark Andrews 
References: <4DFF7876.8050306@globis.net>  <4DFFA72E.3080605@globis.net>  <4DFFBBD8.9050301@globis.net>  <20110621010623.03CB410F29A0@drugs.dv.isc.org> 
In-reply-to: Your message of "Tue, 21 Jun 2011 10:22:01 +0200." 
Date: Tue, 21 Jun 2011 22:02:29 +1000
Message-Id: <20110621120229.DA6C610FB5AE@drugs.dv.isc.org>
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 12:02:49 -0000

In message , Philip Homburg writes:
> In your letter dated Tue, 21 Jun 2011 11:06:22 +1000 you wrote:
> >If CGN added enough delay to make IPv4 slower I might agree with
> >you but they won't.  Additionally race to win always results in
> >redundant connection being made in a correctly working network which
> >is totally unneeded.
> 
> How can you be so sure that CGN doesn't add any delays? If CGN is perfect
> from a performance point of view, then there is no (performance) reason
> to try IPv6 at all.

Please stop trying to put words in my mouth that I didn't say.  I
didn't say that it added no delay.  I said that I don't think CGN's
will have enough delay to cause race to win to favour IPv6 by any
significant amount.  Certainly not enough to shift the majority of
traffic to IPv6.

> I'm not so sure that all ISPs will be able to afford buying CGN capacity 
> for peak load. 

I suspect ISP's will put low volume users onto CGN's and leave high
volume users with public IP addresses.  That will give the biggest
address savings for the smallest outlays.  It also reduces the peak
loads that have to be met.

> I agree that just letting IPv4 and IPv6 connection race is not the right way
> to do things. 
> 
> >HE needs to work well enough with a broken IPv6 network and not
> >cause problems with a working IPv6 network.  This working group
> >seems to be too focused on making a broken network work well verses
> >not making a working network worse.
> 
> Yes. It may be able to do more. But this should be the core functionality.
> 
> >Applications supporting HE will be in use long after the need for
> >HE to address large scale IPv6 brokenness has gone and the failure
> >mode is "this address is unreachable" rather than "IPv6 is unreachable"
> >and all addresses are reachable 99.999% of the time.
> 
> I think both are needed. A dual stack server may have a problem with IPv6, so
> it would be good to avoid connecting over IPv6 to that server. But locally, 
> there may also be a failure that affects just IPv6. 
> 
> >Let getaddrinfo() do its job and sort the addresses.  Try them in
> >the order returned with a short timeout.  Re-use the working address
> >if you need to re-connect to the same host.  This will give you
> >reasonable performance with a broken/tunneled IPv6 or broken/tunneled
> >IPv4 network and good performance with when both stacks are working.
> >
> >If we don't let getaddrinfo() do its job and sort the addresses
> >there will be complaints that the applications don't honour the
> >address selection rules in a few years time.
> 
> I don't care at all about the default policy table. I don't see why HE would
> have to respect that.
> 
> It would be different if an admin specifically installs a different policy
> table. So (at least conceptually) we may need some flags in the getaddrinfo 
> result that specify whether HE should be active at all or whether it is
> allowed to reorder addresses.

Why is it different?  The policy table is supposed to be updatable.  There
is the reason it is called a "default policy table" not "the policy table"
as it was well known that there could be valid reasons to override it.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From pch-b2B3A6689@u-1.phicoh.com  Tue Jun 21 05:35:29 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B493E11E807A for ; Tue, 21 Jun 2011 05:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.513
X-Spam-Level: 
X-Spam-Status: No, score=-8.513 tagged_above=-999 required=5 tests=[AWL=0.086,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcwDnZhvlpwW for ; Tue, 21 Jun 2011 05:35:29 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 51D2711E8078 for ; Tue, 21 Jun 2011 05:35:26 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QZ0Av-0000mEC; Tue, 21 Jun 2011 14:35:25 +0200
Message-Id: 
To: Mark Andrews 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References: <4DFF7876.8050306@globis.net>  <4DFFA72E.3080605@globis.net>  <4DFFBBD8.9050301@globis.net>  <20110621010623.03CB410F29A0@drugs.dv.isc.org>  <20110621120229.DA6C610FB5AE@drugs.dv.isc.org> 
In-reply-to: Your message of "Tue, 21 Jun 2011 22:02:29 +1000 ." <20110621120229.DA6C610FB5AE@drugs.dv.isc.org> 
Date: Tue, 21 Jun 2011 14:35:11 +0200
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 12:35:29 -0000

In your letter dated Tue, 21 Jun 2011 22:02:29 +1000 you wrote:
>In message , Philip Homburg writes:
>> How can you be so sure that CGN doesn't add any delays? If CGN is perfect
>> from a performance point of view, then there is no (performance) reason
>> to try IPv6 at all.
>
>Please stop trying to put words in my mouth that I didn't say.  I
>didn't say that it added no delay.  I said that I don't think CGN's
>will have enough delay to cause race to win to favour IPv6 by any
>significant amount.  Certainly not enough to shift the majority of
>traffic to IPv6.

I think the same comment remains. If CGN perform well enough that (from a 
performance point of view) is is almost indistinguishable from native IPv6,
then why bother with IPv6?

>> I'm not so sure that all ISPs will be able to afford buying CGN capacity 
>> for peak load. 
>
>I suspect ISP's will put low volume users onto CGN's and leave high
>volume users with public IP addresses.  That will give the biggest
>address savings for the smallest outlays.  It also reduces the peak
>loads that have to be met.

Sounds like a great way to fail. 'If you become a high volume user, you get a
public IP'. Great. Let's start downloading.

>> It would be different if an admin specifically installs a different policy
>> table. So (at least conceptually) we may need some flags in the getaddrinfo 
>> result that specify whether HE should be active at all or whether it is
>> allowed to reorder addresses.
>
>Why is it different?  The policy table is supposed to be updatable.  There
>is the reason it is called a "default policy table" not "the policy table"
>as it was well known that there could be valid reasons to override it.

Yes. But with the default policy table in place, there is very good chance
that the 'admin' (in many cases just the owner of the device) didn't think
about it and mostly likely is also quite unaware of the very existance of the
policy table. No need to be overly strict about honoring that table.

So what we need is a way for an admin to disable HE when it is not wanted.



From marka@isc.org  Tue Jun 21 07:38:14 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCE011E814E for ; Tue, 21 Jun 2011 07:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.459
X-Spam-Level: 
X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=1.140,  BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9XnKaEV0KRP for ; Tue, 21 Jun 2011 07:38:13 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id A7FA911E8150 for ; Tue, 21 Jun 2011 07:38:11 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id A00385F9923; Tue, 21 Jun 2011 14:37:26 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 95B9A216C84; Tue, 21 Jun 2011 14:37:19 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4911310FEA11; Wed, 22 Jun 2011 00:37:12 +1000 (EST)
To: Philip Homburg 
From: Mark Andrews 
References: <4DFF7876.8050306@globis.net>  <4DFFA72E.3080605@globis.net>  <4DFFBBD8.9050301@globis.net>  <20110621010623.03CB410F29A0@drugs.dv.isc.org>  <20110621120229.DA6C610FB5AE@drugs.dv.isc.org> 
In-reply-to: Your message of "Tue, 21 Jun 2011 14:35:11 +0200." 
Date: Wed, 22 Jun 2011 00:37:12 +1000
Message-Id: <20110621143712.4911310FEA11@drugs.dv.isc.org>
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 14:38:14 -0000

In message , Philip Homburg writes:
> In your letter dated Tue, 21 Jun 2011 22:02:29 +1000 you wrote:
> >In message , Philip Homburg writes:
> >> How can you be so sure that CGN doesn't add any delays? If CGN is perfect
> >> from a performance point of view, then there is no (performance) reason
> >> to try IPv6 at all.
> >
> >Please stop trying to put words in my mouth that I didn't say.  I
> >didn't say that it added no delay.  I said that I don't think CGN's
> >will have enough delay to cause race to win to favour IPv6 by any
> >significant amount.  Certainly not enough to shift the majority of
> >traffic to IPv6.
> 
> I think the same comment remains. If CGN perform well enough that (from a 
> performance point of view) is is almost indistinguishable from native IPv6,
> then why bother with IPv6?

Because "speed" is not the sole determinate about whether CGN is good or
not.
 
> >> I'm not so sure that all ISPs will be able to afford buying CGN capacity 
> >> for peak load. 
> >
> >I suspect ISP's will put low volume users onto CGN's and leave high
> >volume users with public IP addresses.  That will give the biggest
> >address savings for the smallest outlays.  It also reduces the peak
> >loads that have to be met.
> 
> Sounds like a great way to fail. 'If you become a high volume user, you get a
> public IP'. Great. Let's start downloading.

For lots of us that would just result in a throttled connection
after you have exceeded your montly allowance or you start paying
extra $/MB.

> >> It would be different if an admin specifically installs a different policy
> >> table. So (at least conceptually) we may need some flags in the getaddrinf
> o 
> >> result that specify whether HE should be active at all or whether it is
> >> allowed to reorder addresses.
> >
> >Why is it different?  The policy table is supposed to be updatable.  There
> >is the reason it is called a "default policy table" not "the policy table"
> >as it was well known that there could be valid reasons to override it.
> 
> Yes. But with the default policy table in place, there is very good chance
> that the 'admin' (in many cases just the owner of the device) didn't think
> about it and mostly likely is also quite unaware of the very existance of the
> policy table. No need to be overly strict about honoring that table.
> 
> So what we need is a way for an admin to disable HE when it is not wanted.

Why add more knobs than are actually needed.  Have you tried using
applications connecting from a dual stack box to a dual stack box
with one of the address families down and using a 100ms timer to
switch to the next address returned by getaddrinfo?

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From pch-b2B3A6689@u-1.phicoh.com  Tue Jun 21 08:01:06 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6404C21F84E8 for ; Tue, 21 Jun 2011 08:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.524
X-Spam-Level: 
X-Spam-Status: No, score=-8.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-Ni9ju0P1LI for ; Tue, 21 Jun 2011 08:01:06 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA3821F8458 for ; Tue, 21 Jun 2011 08:01:03 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QZ2Rq-0001gSC; Tue, 21 Jun 2011 17:01:02 +0200
Message-Id: 
To: Mark Andrews 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References: <4DFF7876.8050306@globis.net>  <4DFFA72E.3080605@globis.net>  <4DFFBBD8.9050301@globis.net>  <20110621010623.03CB410F29A0@drugs.dv.isc.org>  <20110621120229.DA6C610FB5AE@drugs.dv.isc.org>  <20110621143712.4911310FEA11@drugs.dv.isc.org> 
In-reply-to: Your message of "Wed, 22 Jun 2011 00:37:12 +1000 ." <20110621143712.4911310FEA11@drugs.dv.isc.org> 
Date: Tue, 21 Jun 2011 17:00:39 +0200
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 15:01:06 -0000

In your letter dated Wed, 22 Jun 2011 00:37:12 +1000 you wrote:
>> I think the same comment remains. If CGN perform well enough that (from a 
>> performance point of view) is is almost indistinguishable from native IPv6,
>> then why bother with IPv6?
>
>Because "speed" is not the sole determinate about whether CGN is good or
>not.

Yes. But low latency without losing packets is hard to get right. So it seems
a good metric for how well a device functions.

>> Sounds like a great way to fail. 'If you become a high volume user, you get 
>a
>> public IP'. Great. Let's start downloading.
>
>For lots of us that would just result in a throttled connection
>after you have exceeded your montly allowance or you start paying
>extra $/MB.

Yes, that's true. 

>Why add more knobs than are actually needed.  Have you tried using
>applications connecting from a dual stack box to a dual stack box
>with one of the address families down and using a 100ms timer to
>switch to the next address returned by getaddrinfo?

I don't know where that 100ms comes from. Many sites need much longer to
connect than that. If you want to avoid spurious connections to IPv4 then
Google's 300 ms is much closer to what you need.

Some sites already put 4 or 5 IPv4 addresses in a DNS reply. If they would do
the same for IPv6 then we talking about a latency of upto 1500 ms. I don't
want to wait that long.



From ayourtch@cisco.com  Tue Jun 21 11:17:15 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC97A11E81A6 for ; Tue, 21 Jun 2011 11:17:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_44=1, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu7ucIVFZ6Wm for ; Tue, 21 Jun 2011 11:17:15 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D6B5711E81A4 for ; Tue, 21 Jun 2011 11:17:14 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from stew-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 p5LIDTUU014906 for ; Tue, 21 Jun 2011 20:13:29 +0200 (CEST)
Received: from dhcp-peg3-vl30-144-254-7-190.cisco.com (dhcp-peg3-vl30-144-254-7-190.cisco.com [144.254.7.190]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p5LIDPSC010894; Tue, 21 Jun 2011 20:13:25 +0200 (CEST)
Date: Tue, 21 Jun 2011 20:13:16 +0200 (CEST)
From: Andrew Yourtchenko 
X-X-Sender: ayourtch@ayourtch-lnx
To: Mark Andrews 
In-Reply-To: <20110621010623.03CB410F29A0@drugs.dv.isc.org>
Message-ID: 
References: <4DFF7876.8050306@globis.net>  <4DFFA72E.3080605@globis.net>  <4DFFBBD8.9050301@globis.net>  <20110621010623.03CB410F29A0@drugs.dv.isc.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: Ray Hunter , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 18:17:15 -0000

On Tue, 21 Jun 2011, Mark Andrews wrote:

> Let getaddrinfo() do its job and sort the addresses.  Try them in
> the order returned with a short timeout.  Re-use the working address

getaddrinfo is too optimistic about insisting on use of IPv6.

There's an interesting concept of label:

#label ::1/128       0
#label ::/0          1
#label 2002::/16     2
#label ::/96         3
#label ::ffff:0:0/96 4
#label fec0::/10     5
#label fc00::/7      6
#label 2001:0::/32   7

These seem to generalize the "address family" in the pure IPv4<->IPv6 
dichotomy.

So, how about this:

take the getaddrinfo() results, and reshuffle the sequence into several 
subsequences, such that each subsequence does not have more than 1 
occurence of an address within a particular label.

Then try to connect with short timeout, in this order.

This way you both honor the order of the 3484 and fail quickly in case the 
entire "class" of the addresses is broken ?

(of course, we're second-guessing what is more likely in case the first 
IPv6 address does not work - that you do not have a connectivity on IPv6 
at all or that it's only the specific IPv6 address that does not work. In 
case of having a chance of trying over more diverse options, I'd rather 
assume the former.)

As a user, I don't care whether the water arrives to my kitchen over 
plastic tubes or the brass tubes - as soon as it is reasonably clean and 
with good pressure.

cheers,
andrew

> if you need to re-connect to the same host.  This will give you
> reasonable performance with a broken/tunneled IPv6 or broken/tunneled
> IPv4 network and good performance with when both stacks are working.
>
> If we don't let getaddrinfo() do its job and sort the addresses
> there will be complaints that the applications don't honour the
> address selection rules in a few years time.
>
> Mark
>
>> Thanks - Fred
>> fred.l.templin@boeing.com
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

From Fred.L.Templin@boeing.com  Tue Jun 21 11:58:08 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29B511E8253 for ; Tue, 21 Jun 2011 11:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level: 
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuwImeSQEsj9 for ; Tue, 21 Jun 2011 11:58:08 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD3511E81DE for ; Tue, 21 Jun 2011 11:58:07 -0700 (PDT)
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 p5LIvs6e023310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Jun 2011 11:57:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p5LIvsVa014806; Tue, 21 Jun 2011 11:57:54 -0700 (PDT)
Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5LIvoi2014650 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 21 Jun 2011 11:57:50 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Tue, 21 Jun 2011 11:57:50 -0700
From: "Templin, Fred L" 
To: Mark Andrews 
Date: Tue, 21 Jun 2011 11:57:49 -0700
Thread-Topic: [v6ops] simplfying Happy Eyeballs further
Thread-Index: Acwvr6u86e/RezCgT+6G76i8k85g9gAlKXrg
Message-ID: 
References: <4DFF7876.8050306@globis.net>  <4DFFA72E.3080605@globis.net>  <4DFFBBD8.9050301@globis.net>  <20110621010623.03CB410F29A0@drugs.dv.isc.org>
In-Reply-To: <20110621010623.03CB410F29A0@drugs.dv.isc.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
Cc: Ray Hunter , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 18:58:08 -0000

Hi Mark,=20

> -----Original Message-----
> From: Mark Andrews [mailto:marka@isc.org]=20
> Sent: Monday, June 20, 2011 6:06 PM
> To: Templin, Fred L
> Cc: Ray Hunter; Cameron Byrne; v6ops@ietf.org WG
> Subject: Re: [v6ops] simplfying Happy Eyeballs further
>=20
>=20
> In message=20
>  .com>, "Templin, Fred L" writes:
> > I think I'm with Ray and the others who liked the idea of a straight
> > race when both IPv4 and IPv6 addresses are available.
>=20
> If CGN added enough delay to make IPv4 slower I might agree with
> you but they won't.  Additionally race to win always results in
> redundant connection being made in a correctly working network which
> is totally unneeded.
>=20
> HE needs to work well enough with a broken IPv6 network and not
> cause problems with a working IPv6 network.  This working group
> seems to be too focused on making a broken network work well verses
> not making a working network worse.
>=20
> Applications supporting HE will be in use long after the need for
> HE to address large scale IPv6 brokenness has gone and the failure
> mode is "this address is unreachable" rather than "IPv6 is=20
> unreachable"
> and all addresses are reachable 99.999% of the time.
>=20
> Let getaddrinfo() do its job and sort the addresses.  Try them in
> the order returned with a short timeout.  Re-use the working address
> if you need to re-connect to the same host.  This will give you
> reasonable performance with a broken/tunneled IPv6 or broken/tunneled
> IPv4 network and good performance with when both stacks are working.
>
> If we don't let getaddrinfo() do its job and sort the addresses
> there will be complaints that the applications don't honour the
> address selection rules in a few years time.

Come to think of it, having a properly sorted list of
candidate addresses would also satisfy my needs, where
sometimes I'd like the applications to prefer an almost
certainly lower latency IPv4 service over an almost
certainly higher latency IPv6 service without having
to go to the trouble of running a race.

I am noticing that this discussion is largely failing to
take into account the *scope* of communications. It may
well be that communcaitions in which both endpoints
reside within the same site may have very different
address selection considerations than when the endpoints
are within different sites.

Thanks - Fred
fred.l.templin@boeing.com=20

> Mark
>=20
> > Thanks - Fred
> > fred.l.templin@boeing.com
> --=20
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> =


From marka@isc.org  Tue Jun 21 15:03:00 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3CB11E810D for ; Tue, 21 Jun 2011 15:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.505
X-Spam-Level: 
X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=1.094,  BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIAVWw05UD6v for ; Tue, 21 Jun 2011 15:03:00 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id EC3BF11E80D5 for ; Tue, 21 Jun 2011 15:02:59 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 109FF5F991D; Tue, 21 Jun 2011 22:02:34 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id ED9AE216C81; Tue, 21 Jun 2011 22:02:31 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id EB417110075E; Wed, 22 Jun 2011 08:02:26 +1000 (EST)
To: Philip Homburg 
From: Mark Andrews 
References: <4DFF7876.8050306@globis.net>  <4DFFA72E.3080605@globis.net>  <4DFFBBD8.9050301@globis.net>  <20110621010623.03CB410F29A0@drugs.dv.isc.org>  <20110621120229.DA6C610FB5AE@drugs.dv.isc.org>  <20110621143712.4911310FEA11@drugs.dv.isc.org> 
In-reply-to: Your message of "Tue, 21 Jun 2011 17:00:39 +0200." 
Date: Wed, 22 Jun 2011 08:02:26 +1000
Message-Id: <20110621220226.EB417110075E@drugs.dv.isc.org>
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 22:03:01 -0000

In message , Philip Homburg writes:
> In your letter dated Wed, 22 Jun 2011 00:37:12 +1000 you wrote:
> >> I think the same comment remains. If CGN perform well enough that (from a 
> >> performance point of view) is is almost indistinguishable from native IPv6
> ,
> >> then why bother with IPv6?
> >
> >Because "speed" is not the sole determinate about whether CGN is good or
> >not.
> 
> Yes. But low latency without losing packets is hard to get right. So it seems
> a good metric for how well a device functions.
> 
> >> Sounds like a great way to fail. 'If you become a high volume user, you ge
> t 
> >a
> >> public IP'. Great. Let's start downloading.
> >
> >For lots of us that would just result in a throttled connection
> >after you have exceeded your montly allowance or you start paying
> >extra $/MB.
> 
> Yes, that's true. 
> 
> >Why add more knobs than are actually needed.  Have you tried using
> >applications connecting from a dual stack box to a dual stack box
> >with one of the address families down and using a 100ms timer to
> >switch to the next address returned by getaddrinfo?
> 
> I don't know where that 100ms comes from. Many sites need much longer to
> connect than that. If you want to avoid spurious connections to IPv4 then
> Google's 300 ms is much closer to what you need.

I'm well aware of the speed of light in glass.  I live far for most
of the rest of the world's population.  100ms is a allowable tunnel
penalty.  It also is good enough for most in continent/country
connections.  Whatever figure we use won't be perfect.

Sydney - Amsterdam is about 220 ms rtt from where I sit in Sydney.
A trans Pacific tunnel adds up to 150-200ms delay depending apon
the destination location.

> Some sites already put 4 or 5 IPv4 addresses in a DNS reply. If they would do
> the same for IPv6 then we talking about a latency of up to 1500 ms. I don't
> want to wait that long.

Only if you assume a 100ms per timeout.  Use 100, 50, 25, 12, 6,
3, 2, 1, 0 which sees you trying all addresses within 200ms.  Or
you could start with 150 and then 75, 37, 18, 9, 4, 2, 1, 0 to have
all address being attempted within 300ms. 

As for your 1500ms that is worst case with the last address tried
succeeding out of 10 addresses.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From dwing@cisco.com  Tue Jun 21 16:28:07 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC26C11E80EC for ; Tue, 21 Jun 2011 16:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.413
X-Spam-Level: 
X-Spam-Status: No, score=-110.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GxwrlWI9IWC for ; Tue, 21 Jun 2011 16:28:07 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC3711E80DA for ; Tue, 21 Jun 2011 16:28:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=628; q=dns/txt; s=iport; t=1308698886; x=1309908486; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=rqP3YbeRBDSsSOxYXjXKPFJ3l1cgZNuT6NslVCrpuwY=; b=DmTSM3RhMJhkbkXUM+7kE1+B0Lyqaf88/HyIs4bU1mGkF6++GKosORM8 rcRXUwra36jRyWXFR7K1Srje3gbWFUQPMdTPbHIPyWdPjAPi/MX43f6sE zzIu3G89qZJ6DcHPGLztiirKCpzZaP6f+eyZFjGjJ+K1UVYJolgQ6WG3a 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAGMoAU6rRDoH/2dsb2JhbABUmViNLneIc6FaniCGKgSHIppq
X-IronPort-AV: E=Sophos;i="4.65,403,1304294400"; d="scan'208";a="719083368"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 21 Jun 2011 23:28:06 +0000
Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5LNS53Y025588; Tue, 21 Jun 2011 23:28:06 GMT
From: "Dan Wing" 
To: "'Mark Andrews'" , "'Philip Homburg'" 
References: <4DFF7876.8050306@globis.net>		<4DFFA72E.3080605@globis.net>		<4DFFBBD8.9050301@globis.net>		<20110621010623.03CB410F29A0@drugs.dv.isc.org>		<20110621120229.DA6C610FB5AE@drugs.dv.isc.org>		<20110621143712.4911310FEA11@drugs.dv.isc.org>	 <20110621220226.EB417110075E@drugs.dv.isc.org>
In-Reply-To: <20110621220226.EB417110075E@drugs.dv.isc.org>
Date: Tue, 21 Jun 2011 16:28:05 -0700
Message-ID: <063a01cc306a$df5fb5c0$9e1f2140$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcwwXwpQEq5gi+avS/SXA0p5ogcWoAAC2F0w
Content-Language: en-us
Cc: v6ops@ietf.org
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 23:28:07 -0000

> Only if you assume a 100ms per timeout.  Use 100, 50, 25, 12, 6,
> 3, 2, 1, 0 which sees you trying all addresses within 200ms.  Or
> you could start with 150 and then 75, 37, 18, 9, 4, 2, 1, 0 to have
> all address being attempted within 300ms.

Most of the IETF's protocols, for good reasons, have exponential backoff
when something is non-responsive.  This is the exact opposite -- if the
network is non-responsive, the network is punished with more aggressive
connection attempts.  Would it contribute (significantly?) to congestion 
on an already-congested network?  Could the idea pass IETF/IESG review?

-d



From marka@isc.org  Tue Jun 21 16:54:38 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D0A21F846D for ; Tue, 21 Jun 2011 16:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.547
X-Spam-Level: 
X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tUNTxP8JZAT for ; Tue, 21 Jun 2011 16:54:37 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA7621F846B for ; Tue, 21 Jun 2011 16:54:37 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 88CF4C9427; Tue, 21 Jun 2011 23:54:27 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 26771216C80; Tue, 21 Jun 2011 23:54:27 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 850B7110529F; Wed, 22 Jun 2011 09:54:21 +1000 (EST)
To: "Dan Wing" 
From: Mark Andrews 
References: <4DFF7876.8050306@globis.net>  <4DFFA72E.3080605@globis.net>  <4DFFBBD8.9050301@globis.net>  <20110621010623.03CB410F29A0@drugs.dv.isc.org>  <20110621120229.DA6C610FB5AE@drugs.dv.isc.org>  <20110621143712.4911310FEA11@drugs.dv.isc.org>  <20110621220226.EB417110075E@drugs.dv.isc.org> <063a01cc306a$df5fb5c0$9e1f2140$@com>
In-reply-to: Your message of "Tue, 21 Jun 2011 16:28:05 MST." <063a01cc306a$df5fb5c0$9e1f2140$@com>
Date: Wed, 22 Jun 2011 09:54:21 +1000
Message-Id: <20110621235421.850B7110529F@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 23:54:38 -0000

In message <063a01cc306a$df5fb5c0$9e1f2140$@com>, "Dan Wing" writes:
> > Only if you assume a 100ms per timeout.  Use 100, 50, 25, 12, 6,
> > 3, 2, 1, 0 which sees you trying all addresses within 200ms.  Or
> > you could start with 150 and then 75, 37, 18, 9, 4, 2, 1, 0 to have
> > all address being attempted within 300ms.
> 
> Most of the IETF's protocols, for good reasons, have exponential backoff
> when something is non-responsive.  This is the exact opposite -- if the
> network is non-responsive, the network is punished with more aggressive
> connection attempts.  Would it contribute (significantly?) to congestion 
> on an already-congested network?  Could the idea pass IETF/IESG review?
> 
> -d

Your not re-attempting the same addresses.  You are attempting
alternate addresses.  You exponentially back of subsequent attempts
to connect to the host if this group fails.

You still end up waiting 30 seconds or so if the host is down for
the proceedure to complete.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From dwing@cisco.com  Tue Jun 21 16:58:16 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A7A21F8503 for ; Tue, 21 Jun 2011 16:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.437
X-Spam-Level: 
X-Spam-Status: No, score=-110.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DPfrEZ2tQDQ for ; Tue, 21 Jun 2011 16:58:15 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 5566E21F850D for ; Tue, 21 Jun 2011 16:58:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1305; q=dns/txt; s=iport; t=1308700687; x=1309910287; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=kekTuTVYRJNvvj57Ugxt/FCaqOMpecDSONGJznYhiG8=; b=BK7DWQk10+vRFpVGpvPzOZoahOBXdoYpCt+uufE1VUkEIgFz/j3+lNKC wXItRlY9Tm6T8NqGgOuxuehtjxbSKHgFWn/4JdOlhLOLsDsvM09xP9fkc AVkXHGsKmzhVUcZ1T6Q5KXMNuWlgdHtz2J559dT+PWqUz6+HfEb4uYSAw Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAC8vAU6rRDoI/2dsb2JhbABUmViNMXeIc6FcnieGKwSHI5pv
X-IronPort-AV: E=Sophos;i="4.65,403,1304294400"; d="scan'208";a="382707367"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 21 Jun 2011 23:58:06 +0000
Received: from dwingWS ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5LNw66F026635; Tue, 21 Jun 2011 23:58:06 GMT
From: "Dan Wing" 
To: "'Mark Andrews'" 
References: <4DFF7876.8050306@globis.net>  <4DFFA72E.3080605@globis.net>  <4DFFBBD8.9050301@globis.net>  <20110621010623.03CB410F29A0@drugs.dv.isc.org>  <20110621120229.DA6C610FB5AE@drugs.dv.isc.org>  <20110621143712.4911310FEA11@drugs.dv.isc.org>  <20110621220226.EB417110075E@drugs.dv.isc.org> <063a01cc306a$df5fb5c0$9e1f2140$@com> <20110621235421.850B7110529F@drugs.dv.isc.org>
In-Reply-To: <20110621235421.850B7110529F@drugs.dv.isc.org>
Date: Tue, 21 Jun 2011 16:58:06 -0700
Message-ID: <065201cc306f$109b2d50$31d187f0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acwwbpt7nf47gNl4Siu5eVmZyCVkUAAADYxA
Content-Language: en-us
Cc: v6ops@ietf.org
Subject: Re: [v6ops] simplfying Happy Eyeballs further
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 23:58:16 -0000

> In message <063a01cc306a$df5fb5c0$9e1f2140$@com>, "Dan Wing" writes:
> > > Only if you assume a 100ms per timeout.  Use 100, 50, 25, 12, 6,
> > > 3, 2, 1, 0 which sees you trying all addresses within 200ms.  Or
> > > you could start with 150 and then 75, 37, 18, 9, 4, 2, 1, 0 to have
> > > all address being attempted within 300ms.
> >
> > Most of the IETF's protocols, for good reasons, have exponential
> backoff
> > when something is non-responsive.  This is the exact opposite -- if
> the
> > network is non-responsive, the network is punished with more
> aggressive
> > connection attempts.  Would it contribute (significantly?) to
> congestion
> > on an already-congested network?  Could the idea pass IETF/IESG
> review?
> >
> > -d
> 
> Your not re-attempting the same addresses.  You are attempting
> alternate addresses.  You exponentially back of subsequent attempts
> to connect to the host if this group fails.
> 
> You still end up waiting 30 seconds or so if the host is down for
> the proceedure to complete.

We had difficulties getting ICE (RFC5245) through IESG and transport 
area review, and it is doing similar things (sending probes to various 
addresses, and wants to send them fast to provide good service to 
the user).  This feels similar.

-d



From fernando.gont.netbook.win@gmail.com  Wed Jun 22 01:02:31 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C1711E80A3; Wed, 22 Jun 2011 01:02:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.106
X-Spam-Level: 
X-Spam-Status: No, score=-3.106 tagged_above=-999 required=5 tests=[AWL=0.493,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmYyT0M9RdEC; Wed, 22 Jun 2011 01:02:28 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 246E711E8083; Wed, 22 Jun 2011 01:02:28 -0700 (PDT)
Received: by gwb20 with SMTP id 20so334461gwb.31 for ; Wed, 22 Jun 2011 01:02:27 -0700 (PDT)
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:content-type:content-transfer-encoding; bh=/YC2z89mL9IHfxEWkBO8Yo5VsclA1BOA4ViUh1zOmFo=; b=Zbk4kP/uQ0yRti1uowJGLsHzx5uL8oEvqY/6q0KuFkNdcgvPLbXaGMmP0IoW6DCuEY IaZ8st7SC6UTQEIJ3URNC/r1FyDbc/Xfyc+Eyh4nBnSc6Ov8xq5wFMEyGl5B2lxGtXMp bfeatc2QArGnc/iWKyC9kKCnVBYaaPdliQKag=
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:content-type :content-transfer-encoding; b=tKUR0Xnm4pWQ6RfhjuzhEpIdktKm9Juv+CEART4oh3e4kYsNc2zdlYr6NZoAf26f6f siSe9cMmpsWcsC86pF9upmtY8IdVFDnSF5AD0I2QB1HwqG/AymXiWahtTw3u/JqQ/gee BeFHrz2MJulT0/RfBlXdRlaAJdx8qMojpe0Ko=
Received: by 10.150.180.20 with SMTP id c20mr513389ybf.413.1308729747433; Wed, 22 Jun 2011 01:02:27 -0700 (PDT)
Received: from [192.168.123.103] ([190.48.241.129]) by mx.google.com with ESMTPS id c26sm332012ana.47.2011.06.22.01.02.18 (version=SSLv3 cipher=OTHER); Wed, 22 Jun 2011 01:02:21 -0700 (PDT)
Sender: Fernando Gont 
Message-ID: <4E01A187.6020008@gont.com.ar>
Date: Wed, 22 Jun 2011 05:02:15 -0300
From: Fernando Gont 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
MIME-Version: 1.0
To: Jean-Michel Combes 
References: <4DF291D0.7080707@gont.com.ar> 
In-Reply-To: 
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IPv6 Operations , "ipv6@ietf.org" 
Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 08:02:32 -0000

Hi, Jean-Michel,

On 06/16/2011 02:13 PM, Jean-Michel Combes wrote:
> IMHO, this draft should update RFC 6105 (If so, RFC6105 reference
> should move from Informative References section to the Normative
> References one).

Yep.


> Just a comment about your example for the fragmentation case with 2
> Destination extensions: from RFC2460 (section 4.1), this only occurs
> when there is also a Routing Header extension, so I have to add a RH
> in your example (better chance to get a fragmentation :))

The specs allow for multiple instances of the same extension headers.
Hence, even if possibly non-sensical, the example in Section 4.1 is
legitime.



> o draft-gont-6man-nd-extension-headers
> 
> IMHO, this is not a good idea to forbid the use of IPv6 extension with
> NDP messages, especially when the reason is partially based on
> implementation issues (i.e. the implementation is not able to process
> an IPv6 packet): 

Well, I'd argue that it is an operational issue, rather than an
implementation issue. -- And chances are that if it is not possible to
implement a simple solution for this concrete problem, some may start
filtering *all* packets that include extension headers (in particular,
those in which the uper layer protocol is not present in the first fragment)



> today, there is no real use of Extension header with
> NDP but, tomorrow, if we need such an use for a solution, what will
> happen?

Among the options is that we could state that implementations should
provide a switch to enable the processing of extension headers, but that
it should default to off.


> Regarding the fragmentation, is it not possible for the RA-Guard
> device to reassemble the fragments and so to be able to check whether
> this a RA message or not?

This would open the door to DoS attacks -- the attacker would simply
fire lots of fragments that would never get to be reassembled. -- then
you're back into the same place (or probably a worse one).

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 hiromi@inetcore.com  Wed Jun 22 01:15:51 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B4B21F847F for ; Wed, 22 Jun 2011 01:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.418
X-Spam-Level: **
X-Spam-Status: No, score=2.418 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHcXsbbppVaS for ; Wed, 22 Jun 2011 01:15:51 -0700 (PDT)
Received: from inc.inetcore.com (p0245a2.tokyff01.ap.so-net.ne.jp [121.2.69.162]) by ietfa.amsl.com (Postfix) with ESMTP id 07A1521F847C for ; Wed, 22 Jun 2011 01:15:49 -0700 (PDT)
Received: from [IPv6:2403:2000:1:3:4c41:8c08:ade5:c7eb] (unknown [IPv6:2403:2000:1:3:4c41:8c08:ade5:c7eb]) by inc.inetcore.com (Postfix) with ESMTPSA id A68A25A2A9C for ; Wed, 22 Jun 2011 17:15:16 +0900 (JST)
Message-ID: <4E01A491.7010205@inetcore.com>
Date: Wed, 22 Jun 2011 17:15:13 +0900
From: Ruri Hiromi 
Organization: INTEC Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: v6ops@ietf.org
References: 	<4DED7A3D.1060008@viagenie.ca>	<8E93014B-E0BC-4001-95F4-D97917CFF2F6@cisco.com>		<34E4F50CAFA10349A41E0756550084FB0690A8EC@PRVPEXVS04.corp.twcable.com> <9101ECA5-40E4-48B0-90DE-ECA3E8C1E8D7@cisco.com>
In-Reply-To: <9101ECA5-40E4-48B0-90DE-ECA3E8C1E8D7@cisco.com>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Subject: Re: [v6ops] Call for agenda items
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 08:15:51 -0000

Hello list,

This might be a trash message but....

Let me know the keywords for finding threads about the "lightning
round", if the discussion has began. I will move to the thread.

For time table issue, will the discussion be held apart from v6ops or
within v6ops? I am(or/and someone from Japan...) able to speak about
Japanese situation and some findings.

Regards,

(2011/06/10 7:13), Fred Baker wrote:
> 
> On Jun 9, 2011, at 2:56 PM, George, Wesley wrote:
> 
>> Personally, I think that it would be better for a generic discussion around World IPv6 day to be part of the Technical Plenary. It has applicability and interest well beyond v6ops.
> 
> Copying the IETF chair and relevant ADs. We need to identify an appropriate speaker, but I think this is a good idea. I could imagine Leslie Daigle, Bob Hinden, or one of a list of luminaries from various operators and enterprises. In fact, I could imagine it being a panel with three or four people coming at it from different perspectives.
> 
>> What would be more useful is to perhaps reserve a couple of 10 minute timeslots for those who have identified a specific operational problem that they discovered during World IPv6 Day that IETF and this WG should be addressing. Almost in the form of a NANOG lightning talk - problem statement, brief explanation, why IETF can/should fix. Then they follow that up with a draft that can be discussed in more detail on-list.
> 
> Speaking for myself, I have a problem with folks speaking with a promise of a follow-up internet draft; I don't think I have ever seen the promised draft. Because of that, I tend to be very firm on the notion that the draft opens the option of giving a talk. Willing to be told I'm wrong, of course.
> 
> But let me turn that around in a different way. Let's use this list as a "lightning round" for the coming two weeks. I'll invite emails of your proposed form - problem statement, brief explanation, why IETF can/should fix, and if obvious, a brief sketch of a possible fix. I'm obviously not looking for tomes, and not looking for statements of the form "my idiot competitor/vendor/customer X..." - those are discussions to have with the relevant idiot.
> 
> I suspect that if we spend the next 1-2 weeks in a lightning round on the list, we will have coalitions interested in specific problems and solutions form, which will be in a position to file a -00 draft by 4 July. Charter guideline - if you're describing a protocol or a change to a protocol, that will wind up in 6man, behave, softwire, or some other appropriate working group. v6ops is for purely operational discussions.
> 
> Those, in turn, may be very useful outputs from the test and inputs to the IETF.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


-- 
---------------
Ruri Hiromi
INTEC Inc.

From rja.lists@gmail.com  Wed Jun 22 04:08:47 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706DE11E80EC; Wed, 22 Jun 2011 04:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.542
X-Spam-Level: 
X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UFlrQx3Eakw; Wed, 22 Jun 2011 04:08:46 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A320811E8076; Wed, 22 Jun 2011 04:08:46 -0700 (PDT)
Received: by vws12 with SMTP id 12so697770vws.31 for ; Wed, 22 Jun 2011 04:08:46 -0700 (PDT)
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:message-id:to:mime-version:x-mailer; bh=hXS7d8LvdktGkkaAFfyI+izS8lbrDjAbherUfbxN6R4=; b=BcD6n+NBHYu3MrHmDm8oDdOFL+m4tFq9NksFxUDHlyLCGRGqjjUE4+Rfhx+tlxvtFN 1s41jd3N96H4gI70rSiK8V3gDcEu3FpB6uM5vABc8yxBFo7dx4gAJynVzyPk3Mtyj5LY L9czHOOVsWIX6GhTEN4KvoGrko4+AttZuL5dY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=KyB0SV5l1xzh6+n5jyHGLsxaCb1PZM899pw3i2DB6ADd5NQHALlanPhpjO84i9eQnc pv6XOe7zIEpUnnMMfwtgzqdnEfTYxdMOqLpqu3+GWIxI0r7GsHft/l4wVy3GWJ3mAlkl 8NgJoz2qK2gYM4Ne3vbL35Et+waHM4hnGMXbs=
Received: by 10.52.178.74 with SMTP id cw10mr761801vdc.141.1308740925954; Wed, 22 Jun 2011 04:08:45 -0700 (PDT)
Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id c9sm118394vdv.40.2011.06.22.04.08.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2011 04:08:45 -0700 (PDT)
From: RJ Atkinson 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 22 Jun 2011 07:08:43 -0400
Message-Id: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>
To: v6ops@ietf.org, ipv6@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 11:08:47 -0000

On Weds, 22 June 2011, Fernando Gont wrote:
On 06/16/2011 02:13 PM, Jean-Michel Combes wrote:
>>  o draft-gont-6man-nd-extension-headers
>> =20
>>  IMHO, this is not a good idea to forbid the use of IPv6 extension =
with
>>  NDP messages, especially when the reason is partially based on
>>  implementation issues (i.e. the implementation is not able to =
process
>>  an IPv6 packet):=20
>=20
> Well, I'd argue that it is an operational issue, rather than an
> implementation issue. -- And chances are that if it is not possible to
> implement a simple solution for this concrete problem, some may start
> filtering *all* packets that include extension headers (in particular,
> those in which the uper layer protocol is not present in the first =
fragment)

I agree with Jean-Michel Combes and disagree with Fernando. =20

It absolutely is an implementation issue -- specifically it is=20
a  "quality of implementation" issue, not a complexity issue.

More importantly, the implementation approach I described on the IPv6=20
list is neither complicated nor computationally expensive.  In fact,=20
supporting the limited set of non-silly-for-ND-packet Extension Headers
has tiny incremental memory footprint and tiny increase in the
instruction count.  The instruction count increase only applies if
an actual Extension Header is encountered, btw.  The code for a L2
device to locate the IPv6 header, read that header, and read into
the ICMP message to determine that a packet is an ND packet *dwarfs*
the code to skip past the small set of reasonable Extension Headers
for ND packets.

Please (re-)read this previous note:
	=
=09

Yours,

Ran


From swmike@swm.pp.se  Wed Jun 22 04:15:29 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696D411E8076; Wed, 22 Jun 2011 04:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwvltjcRT9+4; Wed, 22 Jun 2011 04:15:28 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4CD11E80A9; Wed, 22 Jun 2011 04:15:27 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id DD5D69C; Wed, 22 Jun 2011 13:15:26 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DB5229A; Wed, 22 Jun 2011 13:15:26 +0200 (CEST)
Date: Wed, 22 Jun 2011 13:15:26 +0200 (CEST)
From: Mikael Abrahamsson 
To: RJ Atkinson 
In-Reply-To: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>
Message-ID: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 11:15:29 -0000

On Wed, 22 Jun 2011, RJ Atkinson wrote:

> It absolutely is an implementation issue -- specifically it is a 
> "quality of implementation" issue, not a complexity issue.

I feel that there should be guidance regarding this in the SAVI 
documentation, even if this is only a pointer to another document that 
describes how to parse an IPv6 packet.

Just the same way that it's "obvious" that anyone can spoof RAs on a flat 
L2 lan, it's "obvious" that fragmentation and headers can make parsing 
actual payload harder and needs to be handled. These two "obvious" have 
historically been overlooked numerous times.

Just the same way describing how to do SAVI L2.5 functionality to solve 
different security implications needs to be done to provide guidance to 
vendors, I also feel that they need to be helped to handle fragmentation 
attacks.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From pch-b2B3A6689@u-1.phicoh.com  Wed Jun 22 04:19:03 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476A511E80F2; Wed, 22 Jun 2011 04:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.532
X-Spam-Level: 
X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwNJAx8ZU5eg; Wed, 22 Jun 2011 04:19:02 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9B311E80BC; Wed, 22 Jun 2011 04:19:01 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QZLSP-0001h8C; Wed, 22 Jun 2011 13:18:53 +0200
Message-Id: 
To: RJ Atkinson 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
In-reply-to: Your message of "Wed, 22 Jun 2011 07:08:43 -0400 ." <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> 
Date: Wed, 22 Jun 2011 13:18:49 +0200
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 11:19:03 -0000

In your letter dated Wed, 22 Jun 2011 07:08:43 -0400 you wrote:
>More importantly, the implementation approach I described on the IPv6 
>list is neither complicated nor computationally expensive.  In fact, 
>supporting the limited set of non-silly-for-ND-packet Extension Headers
>has tiny incremental memory footprint and tiny increase in the
>instruction count.  The instruction count increase only applies if
>an actual Extension Header is encountered, btw.  The code for a L2
>device to locate the IPv6 header, read that header, and read into
>the ICMP message to determine that a packet is an ND packet *dwarfs*
>the code to skip past the small set of reasonable Extension Headers
>for ND packets.

I have to admit I don't know much about the internals of L2 switches. But
my mental model of a 10 Gbit/s ethernet switch is that of an ASIC/FPGA that
does almost all forwarding with the CPU just for management.

I've no idea how expensive it would be to parse extension headers in an ASIC.

I think it is a bit ironic that if a L2 device has to parse all extension
headers, that then L2 switching of IPv6 packets will be more expensive that
L3 routing them.



From rja.lists@gmail.com  Wed Jun 22 04:26:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E591211E80BC; Wed, 22 Jun 2011 04:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.546
X-Spam-Level: 
X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7UMCfJ7AwAh; Wed, 22 Jun 2011 04:26:30 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 465F011E80F2; Wed, 22 Jun 2011 04:26:30 -0700 (PDT)
Received: by gya6 with SMTP id 6so425010gya.31 for ; Wed, 22 Jun 2011 04:26:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=/3cQW3CutWt6V/t6i5oqm9K6xSTVY1piZ6L9QsseSS8=; b=uNqty9ts3/xmBbqZL0iyu95PJQqiVKOPawCCKo7lD+A26YjVNSSUg2FAincbeuVKJl Bj37F6v2NNLsNn5oabX0h62oNBhBiR3Z9ZWSEJPCnZbWnIfwpmOZ1tcp7Rotij7y19yq GYzTUjnuWkiAUYWTeoa9rp+Lb5hv9xUI/C8wo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=mr7D7xv7PObEO2tGZYxT5QMb7XUETPgxSVFhFA2XoB3UbUNQqTJhppoMtVyAaLE8IA SAqXwQWjh3wWnRKr5hnr5YYvRH2KgyiXExJRh5nq9fNAiLgqxLPKl8JWMHP0GyIG6WzV GYwhOVUrogLWzzZg4vhATEiwwiGxbTKdECbk4=
Received: by 10.150.63.19 with SMTP id l19mr596628yba.369.1308741989508; Wed, 22 Jun 2011 04:26:29 -0700 (PDT)
Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id u17sm134379ybl.3.2011.06.22.04.26.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2011 04:26:28 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: RJ Atkinson 
In-Reply-To: 
Date: Wed, 22 Jun 2011 07:25:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <41367707-D357-4A1E-BA0F-CC2EE10521F1@gmail.com>
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> 
To: v6ops@ietf.org, ipv6@ietf.org
X-Mailer: Apple Mail (2.1084)
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 11:26:31 -0000

On 22  Jun 2011, at 07:15 , Mikael Abrahamsson wrote:
> On Wed, 22 Jun 2011, RJ Atkinson wrote:
>> It absolutely is an implementation issue -- specifically it is
>> a "quality of implementation" issue, not a complexity issue.
>=20
> I feel that there should be guidance regarding this in the SAVI
> documentation, even if this is only a pointer to another document
> that describes how to parse an IPv6 packet.

That seems useful to me. =20

> Just the same way that it's "obvious" that anyone can spoof RAs
> on a flat L2 lan, it's "obvious" that fragmentation and headers
> can make parsing actual payload harder and needs to be handled.
> These two "obvious" have historically been overlooked numerous times.

As the 17th June 2011 note I pointed to earlier today,=20
but did not repeat in its entirety, observed:

A) the "Fragmentation Header" is clearly a security risk,
   so banning that makes sense.

B) packet re-assembly can be expensive in (memory footprint, =
computation).

C) the "Routing Header" better not be in an ND packet in any case,
   since ND packets are supposedly link-local, and therefore not =
applicable=20
   for any ND packet, so banning that makes sense.


That same note pointed out that the above analysis is NOT true
for selected other IPv6 Extension Headers (i.e. the ones that=20
might actually be useful with ND), for example:

1) Hop-by-Hop Options header, which safely and trivially
   can be parsed past by a L2 device just implementing an RA Guard

2) Destination Options header, which also safely and trivially
   can be parsed past by a L2 device just implementing an RA Guard.
=20
> Just the same way describing how to do SAVI L2.5 functionality to =
solve
> different security implications needs to be done to provide guidance
> to vendors, I also feel that they need to be helped to handle =
fragmentation attacks.

That also sounds useful to me.

Cheers,

Ran


From ipng@69706e6720323030352d30312d31340a.nosense.org  Wed Jun 22 04:34:59 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02CE11E810F; Wed, 22 Jun 2011 04:34:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.82
X-Spam-Level: 
X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=1.075,  BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ru513YrG-Ff6; Wed, 22 Jun 2011 04:34:58 -0700 (PDT)
Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id EE59911E8104; Wed, 22 Jun 2011 04:34:57 -0700 (PDT)
Received: from 219-90-231-100.ip.adam.com.au ([219.90.231.100] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QZLhs-0004iP-BS; Wed, 22 Jun 2011 21:04:52 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 68A993B341; Wed, 22 Jun 2011 21:04:51 +0930 (CST)
Date: Wed, 22 Jun 2011 21:04:51 +0930
From: Mark Smith 
To: Philip Homburg 
Message-ID: <20110622210451.60ad8bce@opy.nosense.org>
In-Reply-To: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> 
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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@ietf.org, v6ops@ietf.org, RJ Atkinson 
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 11:34:59 -0000

On Wed, 22 Jun 2011 13:18:49 +0200
Philip Homburg  wrote:

> In your letter dated Wed, 22 Jun 2011 07:08:43 -0400 you wrote:
> >More importantly, the implementation approach I described on the IPv6 
> >list is neither complicated nor computationally expensive.  In fact, 
> >supporting the limited set of non-silly-for-ND-packet Extension Headers
> >has tiny incremental memory footprint and tiny increase in the
> >instruction count.  The instruction count increase only applies if
> >an actual Extension Header is encountered, btw.  The code for a L2
> >device to locate the IPv6 header, read that header, and read into
> >the ICMP message to determine that a packet is an ND packet *dwarfs*
> >the code to skip past the small set of reasonable Extension Headers
> >for ND packets.
> 
> I have to admit I don't know much about the internals of L2 switches. But
> my mental model of a 10 Gbit/s ethernet switch is that of an ASIC/FPGA that
> does almost all forwarding with the CPU just for management.
> 
> I've no idea how expensive it would be to parse extension headers in an ASIC.
> 
> I think it is a bit ironic that if a L2 device has to parse all extension
> headers, that then L2 switching of IPv6 packets will be more expensive that
> L3 routing them.
> 

It may be getting to the point where it'd probably be easier
to address these issues by taking away hosts' ability to multicast to
other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke
mode of LAN operation, allowing the designated routers to also act as
traffic sanitisers for on-link inter-host traffic.

Regards,
Mark.

From swmike@swm.pp.se  Wed Jun 22 04:41:34 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED69A21F84CA; Wed, 22 Jun 2011 04:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJrjv04kNE5F; Wed, 22 Jun 2011 04:41:34 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFC921F84C8; Wed, 22 Jun 2011 04:41:33 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id E1D4C9C; Wed, 22 Jun 2011 13:41:32 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DE0C19A; Wed, 22 Jun 2011 13:41:32 +0200 (CEST)
Date: Wed, 22 Jun 2011 13:41:32 +0200 (CEST)
From: Mikael Abrahamsson 
To: ipv6@ietf.org
In-Reply-To: <20110622210451.60ad8bce@opy.nosense.org>
Message-ID: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
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] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 11:41:35 -0000

On Wed, 22 Jun 2011, Mark Smith wrote:

> It may be getting to the point where it'd probably be easier to address 
> these issues by taking away hosts' ability to multicast to other hosts 
> on the same segment i.e. switch to an NBMA/hub-and-spoke mode of LAN 
> operation, allowing the designated routers to also act as traffic 
> sanitisers for on-link inter-host traffic.

I agree, that's the deployment model I advocate for hostile scenarios. Use 
DHCPv6 for stateful addressing, advertise default GW via RA, don't 
advertise any on-link prefix, and make sure hosts can't L2 communicate at 
all with each other by means of enforcement in switches (or just separate 
them into different L2 domains).

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From rja.lists@gmail.com  Wed Jun 22 05:04:42 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD99F11E80EF; Wed, 22 Jun 2011 05:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.549
X-Spam-Level: 
X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=1.050,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EslmHyhT0Gv6; Wed, 22 Jun 2011 05:04:42 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id CBBDB11E80BC; Wed, 22 Jun 2011 05:04:41 -0700 (PDT)
Received: by qwc23 with SMTP id 23so504774qwc.31 for ; Wed, 22 Jun 2011 05:04:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=beP2+K2W3+PrXc7PNCdM7T1yro8qQ9IKGYYzxcaDO8A=; b=vbzgvscXvO6OOC8JyiMbnar95n/YWY4bdhhhopMGRfSwOJwBJVvFiI7GFHuBDvlGMT rLJOzDlMus+YH4+L+vYIwJMEMyn78MpDe2KLgcmWvhCUDiTufYZrcC07ZD8DwFWopvw0 gxgM0NZ/yILVyRnt0XEeupMqhZW1OQd01uy+s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=tEX1cytri+0snGsDpXtMkK8aIS85TCLEK9oyxGEm52veX61a1go8ZTf8k2vGOgdwyE oav5aam0PwLFJCO/BWNLftYo9G+o5E1dwWd0sP9VSfSVZDZWnllAPVzRgiXQPJbA5vJJ rpuQ15I5bLESgTq8aIrHs9oAH5Wy8PNrQdiEY=
Received: by 10.224.183.206 with SMTP id ch14mr381242qab.343.1308744281101; Wed, 22 Jun 2011 05:04:41 -0700 (PDT)
Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id p10sm373900qcu.13.2011.06.22.05.04.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2011 05:04:40 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: RJ Atkinson 
In-Reply-To: 
Date: Wed, 22 Jun 2011 08:04:39 -0400
Content-Transfer-Encoding: 7bit
Message-Id: 
References: 
To: v6ops@ietf.org, ipv6@ietf.org
X-Mailer: Apple Mail (2.1084)
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 12:04:42 -0000

On 22  Jun 2011, at 07:18 , Philip Homburg wrote:
> In your letter dated Wed, 22 Jun 2011 07:08:43 -0400 you wrote:
>> More importantly, the implementation approach I described on the IPv6 
>> list is neither complicated nor computationally expensive.  In fact, 
>> supporting the limited set of non-silly-for-ND-packet Extension Headers
>> has tiny incremental memory footprint and tiny increase in the
>> instruction count.  The instruction count increase only applies if
>> an actual Extension Header is encountered, btw.  The code for a L2
>> device to locate the IPv6 header, read that header, and read into
>> the ICMP message to determine that a packet is an ND packet *dwarfs*
>> the code to skip past the small set of reasonable Extension Headers
>> for ND packets.
> 
> I have to admit I don't know much about the internals of L2 switches.
> But my mental model of a 10 Gbit/s ethernet switch is that of an
> ASIC/FPGA that does almost all forwarding with the CPU just for management.

I spent most of the last decade building high-performance
Ethernet switches.  Your mental model is generally the case,
but that ASIC/FPGA often already includes IPv4/IPv6 routing
capability including some degree of packet parsing capability.

(Even the low-cost "consumer electronics" L2 switches now
often/commonly use a commodity ASIC that includes at least 
some L3 capabilities -- although a given product might or
might not software-enable those chip features.)

Some chips can parse/parse-past any legal combination of IPv4/IPv6
headers at wire-speed.  Some can parse past a subset, again at
wire-speed, with the most common IPv6 subset being the Routing Header, 
Destination Options header, and Hop-by-Hop header.

I know of at least 2 Ethernet switch vendors that already have
sold/deployed ASIC/FPGA-based switches that can parse past IPv6 
extension headers (i.e. to read transport-layer header information 
& provide wire-speed ACLs, to handle an ICMPv6 message, etc.).  

For the genuine L2-only ASIC/FPGA devices, those without ANY
L3 capabilities, any form of Fernando's proposal will require 
that **all** IPv6 packets, anything with (EtherType=0x86dd) 
not just all IPv6 ND packets, be sent via the CPU.  As you noted 
later on, this precise situation leads to real challenges in 
throughput, switch resilience, etc.

In such a pure-L2-only case, the big performance hit is parsing 
INTO the IPv6 packet in the first place.  One won't even be able 
to detect whether a packet is an ND packet until one has parsed
inside the ICMPv6 header.  Best case, getting that far in is
a bunch of CPU instructions for each IPv6 packet.  Once one
has decided to do that, which might or might not be a wise
product-management decision, then parsing past the Dest Opts
Header or Hop-by-Hop Header is a tiny incremental hit that
applies only to those packets with such headers.

Of course, packet reassembly IS expensive.  This is why my
proposal does NOT disagree with Fernando's proposal to
outright ban the IPv6 Fragment Header for IPv6 ND packets.

> I've no idea how expensive it would be to parse
> extension headers in an ASIC.

Good question.  I have data.

For one implementation I am very familiar with, that Verilog 
did not significantly increase the gate count, did not make gate 
layout/place harder, and did not increase the die size.  Folks I know 
who worked on a genetically different ASIC with similar packet parsing 
capabilities tell me their experience was roughly the same 
(i.e. gate count increase was minor, no new layout/place issues, 
and no increase in chip die size).
 
So my answer would be "not very expensive", based on actual 
experience with this in a commercial product environment.

> I think it is a bit ironic that if a L2 device has to parse
> all extension headers, that then L2 switching of IPv6 packets
> will be more expensive that L3 routing them.

For a pure L2-device, without any L3 hardware capabilities,
one imagines that the most common product-manaagement decision 
would be to ignore Fernando's entire spec (and not claim 
to support it).

Again, for a pure L2-device, the expensive part of Fernando's spec 
is parsing from (EtherType==0x86dd) and start-of-frame to the point 
where the switch can learn that the packet contains ICMPv6 and 
that the ICMP Type indicates an ND packet.  Parsing past the 
Dest Opts header & Hop-by-Hop header is a tiny incremental CPU
hit (a few assembler instructions) on that basic unavoidable cost.

For an L3-capable chip, it often is still possible to use some
of the chip's L3 features (e.g. packet parsing) even when the
chip is bridging a frame instead of routing a packet.  So for
the devices using an L3-capable chip, it is not necessarily
the case that L2 switching would be more expensive than L3
routing.  (Obviously L2 switching with an RA-Guard could be more
expensive than L3 routing with RA-Guard for particular chip
implementations; I have no doubt that some such chips
both exist and are present in some commonly deployed devices.)

I do think there is a real question of how deployable Fernando's
RA Guard proposal will be *in the near term*.  In the longer term,
one would hope that the chipset vendors that need to spin
a chip would plan for this whenever they do such a spin.
(Ultimately, the market will decide whether Fernando's spec 
deploys, even if the IETF endorses it, as is true with so many 
notional capabilities.)

Cheers,

Ran




From rja.lists@gmail.com  Wed Jun 22 05:11:02 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C82911E8103; Wed, 22 Jun 2011 05:11:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.611
X-Spam-Level: 
X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K2nAmWC6zX3; Wed, 22 Jun 2011 05:11:00 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF08611E8130; Wed, 22 Jun 2011 05:10:30 -0700 (PDT)
Received: by vxi40 with SMTP id 40so741000vxi.31 for ; Wed, 22 Jun 2011 05:10:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=7MJM4abPoPN0d7FzVl4f8o+FnWOs8NwrRv69wkcFTIw=; b=liPRX99zW2gmVyRurxvirDlFaiPeaA39au1KMYbXFvO6nVbZPAu1d0G898EcXvx0j7 4bSngtNdCOHiXJVa+kfxefS/7h4lnX4KvDr1nPxTaBbPF5eEM6Hev/KMq2qV16rCm/XX Mh+j6FSW5gj2SN52qjc1TY0JuOgymQ5rCkkww=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=GFehdTpb7n6EKAc4fF+BkC4mEQ3yXuN63gOFcN64wKlu38mPvAgGN1px4KH2345FbJ oCfJnXNQX/Tz8HBeJyqHgCi4V7o/qc0OQT4V7JwQ3zo41f3nGNovKHTmfOcC6sW1uGe5 hVTSwIaZHdpe5oCKk8Wyu30cU+HwkHw3Sag7M=
Received: by 10.220.5.10 with SMTP id 10mr227760vct.107.1308744630189; Wed, 22 Jun 2011 05:10:30 -0700 (PDT)
Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id dt10sm59398vcb.24.2011.06.22.05.10.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2011 05:10:29 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: RJ Atkinson 
In-Reply-To: <20110622210451.60ad8bce@opy.nosense.org>
Date: Wed, 22 Jun 2011 08:10:27 -0400
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>
To: v6ops@ietf.org, ipv6@ietf.org
X-Mailer: Apple Mail (2.1084)
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 12:11:02 -0000

On 22  Jun 2011, at 07:34 , Mark Smith wrote:
> It may be getting to the point where it'd probably be easier
> to address these issues by taking away hosts' ability to multicast
> to other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke
> mode of LAN operation, allowing the designated routers to also
> act as traffic sanitisers for on-link inter-host traffic.

That is possible; doing so would create a new and different set 
of operational issues and implementation issues.  It isn't
immediately obvious to me that the alternative set of issues would be 
simpler/cheaper/easier than the issues Fernando's proposal raises.

Another more fundamental question is how much operational risk the 
folks who deploy edge networks believe they have, and how much 
operational risk those folks are comfortable with.  Some or many such 
operational folks might find all of these concepts to have excessive 
capital and operational expense for the perceived risk reduction.
They might conclude that the "cure" is worse than the "disease".

Yours, 

Ran


From Fred.L.Templin@boeing.com  Wed Jun 22 08:14:00 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953AA11E80E4 for ; Wed, 22 Jun 2011 08:14:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.165
X-Spam-Level: 
X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCxSNfW394i6 for ; Wed, 22 Jun 2011 08:13:59 -0700 (PDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC7411E80B8 for ; Wed, 22 Jun 2011 08:13:59 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5MFDOM2019507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Jun 2011 10:13:25 -0500 (CDT)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p5MF5wDL012149; Wed, 22 Jun 2011 08:05:58 -0700 (PDT)
Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5MF5vvk012125 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 22 Jun 2011 08:05:57 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Wed, 22 Jun 2011 08:13:23 -0700
From: "Templin, Fred L" 
To: Joel Jaeggli 
Date: Wed, 22 Jun 2011 08:13:22 -0700
Thread-Topic: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?
Thread-Index: AcwtJ7+vRpD6lZYVTg2di+8xEeOXSwDxF7sw
Message-ID: 
References:  <31BCF9EC-7A49-4C5B-B62A-CAECF66F23F1@bogus.com>
In-Reply-To: <31BCF9EC-7A49-4C5B-B62A-CAECF66F23F1@bogus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A65C6A8F723FXCHNW01Vnwnos_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 15:14:00 -0000

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

Hi Joel,

Thanks for your comments, and see below for responses:

________________________________
From: Joel Jaeggli [mailto:joelja@bogus.com]
Sent: Friday, June 17, 2011 12:50 PM
To: Templin, Fred L
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?

On Jun 3, 2011, at 8:13 AM, Templin, Fred L wrote:

Hello,

Significant improvements have been made to this document
(below) based on comments received and new observations.
IMHO, this is an important document for enabling transition
to IPv6 within IPv4 sites; hence, I would like to call for
working group adoption at this time.

Thanks - Fred
fred.l.templin@boeing.com


Replying to this message as a way to maintain the threading. these notes ar=
e relative to the current version of the draft which I reviewed last week:

http://tools.ietf.org/html/draft-templin-v6ops-isops-10

So I tried for a while to separate the operational advice that could be app=
lied to my 2005 era knowledge of isatap and there's  quite a few things tha=
t jive with that (tunnel loops for example).
OK.
In other cases such isatap dhcpv6 (4.5) I'm a bit-off in the weeds, what im=
plementations are capable of doing that? Are we recommending that they do i=
t? do they already?
I can't speak for current implementations, but the DHCPv6 approach is
based on the fact that address and prefix assignment on IPv6 interfaces
are seperable functions. IPv6 prefixes assigned to ISATAP interfaces can
only be used for autoconfiguration of ISATAP addresses and not ordinary
IPv6 addresses. However, an ordinary IPv6 address can be assigned to
an ISATAP interface the same as for any other IPv6 interface as long as
it is not covered by a prefix assigned to the interface.
Regarding aero (section 4.6) that looks pretty much like new work or an ext=
ension to the specification.
AERO is a new but backwards-compatible method of doing redirection
of an on-link neighbor to another on-link neighbor. However, ISATAP
interfaces can still use standards ICMPv6 Redirect messages the same
as for any IPv6 interface. Advertising ISATAP routers should only send
ICMPv6 redirects when they are certain that the redirected ISATAP node
can tunnel packets directly to the target of the redirect, however. Perhaps
a few more words saying explicitly that standards ICMPv6 redirects are
still supported would help?
Are there participants with extant isatap deployements or host implementati=
ons or knowledge fresher than mine that would care to comment on this draft=
.

There are certainly vendors who are shipping ISATAP in their products
today. Perhaps they can comment.
section 9 alternative approaches, there's some consensus that rfc 3056 was =
never really deployed so the reference to 6to4 should probably be to 3068

OK - I can fix this.

Thanks - Fred
fred.l.templin@boeing.com

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







Hi Joel,


 


Thanks for your comments, and see below for=20
responses:




  

  

  From: Joel Jaeggli [mailto:joelja@bog=
us.com]=20
  
Sent: Friday, June 17, 2011 12:50 PM
To: Templin, Fr=
ed=20
  L
Cc: v6ops@ietf.org
Subject: Re: [v6ops]=20
  'draft-templin-v6ops-isops' as v6ops wg item?


  

  
On Jun 3, 2011, at 8:13 AM, Templin, Fred L wrote:

  

  


  

    
Hello,

Significant improvements have been made to this=20
    document
(below) based on comments received and new=20
    observations.
IMHO, this is an important document for enabling=20
    transition
to IPv6 within IPv4 sites; hence, I would like to call=20
    for
working group adoption at this time.

Thanks - Fred
fred.l.templin@boeing.com=



Replying=20
  to this message as a way to maintain the threading. these notes are relat=
ive=20
  to the current version of the draft which I reviewed last week:

  


  
http://t=
ools.ietf.org/html/draft-templin-v6ops-isops-10

  


  
So I=
 tried=20
  for a while to separate the operational advice that could be applied to m=
y=20
  2005 era knowledge of isatap and there's  quite a few things that ji=
ve=20
  with that (tunnel loops for example). 


OK.  



  
In o=
ther=20
  cases such isatap dhcpv6 (4.5) I'm a bit-off in the weeds, what=20
  implementations are capable of doing that? Are we recommending that they =
do=20
  it? do they already? 


I can't speak for=20
current implementations, but the DHCPv6 approach=20
is


based on the fact th=
at address=20
and prefix assignment on IPv6 interfaces


are seperable functi=
ons. IPv6=20
prefixes assigned to ISATAP interfaces can


only be used for=20
autoconfiguration of ISATAP addresses and not=20
ordinary


IPv6 addresses. Howe=
ver, an=20
ordinary IPv6 address can be assigned to


an ISATAP interface =
the same as=20
for any other IPv6 interface as long as


it is not covered by=
 a prefix=20
assigned to the interface.



  
Rega=
rding=20
  aero (section 4.6) that looks pretty much like new work or an extension t=
o the=20
  specification. 


AERO is a new but=20
backwards-compatible method of doing redirection


of an on-link neighb=
or to=20
another on-link neighbor. However, ISATAP


interfaces can still=
 use=20
standards ICMPv6 Redirect messages the same


as for any IPv6=20
interface. Advertising ISATAP routers should only=20
send


ICMPv6 redirects whe=
n they are=20
certain that the redirected ISATAP node


can tunnel pack=
ets=20
directly to the target of the redirect, however.=20
Perhaps


a few more words say=
ing=20
explicitly that standards ICMPv6 redirects are


still supported woul=
d=20
help? 



  
Are =
there=20
  participants with extant isatap deployements or host implementations or=20
  knowledge fresher than mine that would care to comment on this draft. 

  
 


There are certainly =
vendors who=20
are shipping ISATAP in their products


today. Perhaps they =
can=20
comment. 



  
sect=
ion 9=20
  alternative approaches, there's some consensus that rfc 3056 was never re=
ally=20
  deployed so the reference to 6to4 should probably be to 3068 

  
 


OK - I can fix=20
this.


 


Thanks -=20
Fred


fred.l.templin@boeing.com


--_000_E1829B60731D1740BB7A0626B4FAF0A65C6A8F723FXCHNW01Vnwnos_--

From joelja@bogus.com  Wed Jun 22 08:24:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D7511E8135; Wed, 22 Jun 2011 08:24:16 -0700 (PDT)
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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfzPJwGfPoRZ; Wed, 22 Jun 2011 08:24:15 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 918AC11E8141; Wed, 22 Jun 2011 08:24:11 -0700 (PDT)
Received: from [10.168.76.183] (8.sub-166-250-39.myvzw.com [166.250.39.8]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p5MFO68S038499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Jun 2011 15:24:08 GMT (envelope-from joelja@bogus.com)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Joel Jaeggli 
In-Reply-To: 
Date: Wed, 22 Jun 2011 08:24:01 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org> 
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.1084)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 22 Jun 2011 15:24:09 +0000 (UTC)
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 15:24:17 -0000

On Jun 22, 2011, at 4:41 AM, Mikael Abrahamsson wrote:

> On Wed, 22 Jun 2011, Mark Smith wrote:
>=20
>> It may be getting to the point where it'd probably be easier to =
address these issues by taking away hosts' ability to multicast to other =
hosts on the same segment i.e. switch to an NBMA/hub-and-spoke mode of =
LAN operation, allowing the designated routers to also act as traffic =
sanitisers for on-link inter-host traffic.
>=20
> I agree, that's the deployment model I advocate for hostile scenarios. =
Use DHCPv6 for stateful addressing, advertise default GW via RA, don't =
advertise any on-link prefix, and make sure hosts can't L2 communicate =
at all with each other by means of enforcement in switches (or just =
separate them into different L2 domains).

controller based wireless deployments can largely do this for ipv4 (and =
v6 to some extent) today. it's a fairly heavyweight approach for lightly =
managed networks.

> --=20
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20


From Fred.L.Templin@boeing.com  Wed Jun 22 08:39:23 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112BA11E80BD; Wed, 22 Jun 2011 08:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level: 
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkFKMPMNPvZY; Wed, 22 Jun 2011 08:39:20 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id BD3AE11E80B2; Wed, 22 Jun 2011 08:39:20 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5MFdE2c028406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Jun 2011 08:39:15 -0700 (PDT)
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 p5MFdE56015930; Wed, 22 Jun 2011 10:39:14 -0500 (CDT)
Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5MFdDLG015900 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 22 Jun 2011 10:39:14 -0500 (CDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Wed, 22 Jun 2011 08:39:13 -0700
From: "Templin, Fred L" 
To: Mikael Abrahamsson , "ipv6@ietf.org" 
Date: Wed, 22 Jun 2011 08:39:12 -0700
Thread-Topic: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
Thread-Index: Acww0V/B8oFydOorTD28z0GyW5fq1gAH/1mQ
Message-ID: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org> 
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] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 15:39:23 -0000

Mark and Mikael,

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20
> On Behalf Of Mikael Abrahamsson
> Sent: Wednesday, June 22, 2011 4:42 AM
> To: ipv6@ietf.org
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND=20
> and extension headers)
>=20
> On Wed, 22 Jun 2011, Mark Smith wrote:
>=20
> > It may be getting to the point where it'd probably be=20
> easier to address=20
> > these issues by taking away hosts' ability to multicast to=20
> other hosts=20
> > on the same segment i.e. switch to an NBMA/hub-and-spoke=20
> mode of LAN=20
> > operation, allowing the designated routers to also act as traffic=20
> > sanitisers for on-link inter-host traffic.

That's just how ISATAP works when the advertising
ISATAP routers do not advertise on-link IPV6 prefixes.
However, the advertising ISATP routers can also send
ICMPv6 Redirects - which is really still in keeping
with your characterization of "traffic sanitiser".

> I agree, that's the deployment model I advocate for hostile=20
> scenarios. Use=20
> DHCPv6 for stateful addressing, advertise default GW via RA, don't=20
> advertise any on-link prefix,

That's exactly the model I had in mind for ISATAP.

> and make sure hosts can't L2=20
> communicate at=20
> all with each other by means of enforcement in switches (or=20
> just separate=20
> them into different L2 domains).

This would certainly enforce a true hub-and-spokes,
but may be overly restrictive in some environments.
For example, if a host has a way of knowing at L2
that a packet has come from a trusted router and not
an anonymous node on the link then there may not be
such a strong requirement for L2 segregation. ISATAP
provides such a means.

Thanks - Fred
fred.l.templin@boeing.com

> --=20
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> =

From fred@cisco.com  Wed Jun 22 09:29:45 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEAE21F84AA for ; Wed, 22 Jun 2011 09:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.442
X-Spam-Level: 
X-Spam-Status: No, score=-110.442 tagged_above=-999 required=5 tests=[AWL=-0.443, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdnzYsw+RfzA for ; Wed, 22 Jun 2011 09:29:44 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3A38E11E8127 for ; Wed, 22 Jun 2011 09:29:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1932; q=dns/txt; s=iport; t=1308760184; x=1309969784; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=tHfeAGCwdvTyRnUlIz+jq/gY0VDUyGAP/DWmX04tjic=; b=focj/HJ3BE4cKCLsL7QodVvyD3/Y9e3+wTMFuQOL2n47kL0dp95iWiTH krocW3/z/J84959C3IOg4PZWq7g8dPSF066OAWDwALn+gxotC1UBQnzt7 tj7waPOf9JLcIdGXVr6rSFfTUUj3KqVWPHnPjPPYNA/MMnuOx8ecbP9zd w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAPcXAk6rRDoI/2dsb2JhbABUpw93iHOhKp5Rhi0EhyWKRYRli0c
X-IronPort-AV: E=Sophos;i="4.65,407,1304294400"; d="scan'208";a="344167741"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 22 Jun 2011 16:29:43 +0000
Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5MGTcNE022862; Wed, 22 Jun 2011 16:29:43 GMT
Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 22 Jun 2011 09:29:43 -0700
X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 22 Jun 2011 09:29:43 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
In-Reply-To: <4E01A491.7010205@inetcore.com>
Date: Wed, 22 Jun 2011 09:29:28 -0700
Message-Id: <3C8A0CB8-C5E9-43D9-9C4A-F7C1DF5C88C5@cisco.com>
References: 	<4DED7A3D.1060008@viagenie.ca>	<8E93014B-E0BC-4001-95F4-D97917CFF2F6@cisco.com>		<34E4F50CAFA10349A41E0756550084FB0690A8EC@PRVPEXVS04.corp.twcable.com> <9101ECA5-40E4-48B0-90DE-ECA3E8C1E8D7@cisco.com> <4E01A491.7010205@inetcore.com>
To: Ruri Hiromi 
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Call for agenda items
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 16:29:45 -0000

On Jun 22, 2011, at 1:15 AM, Ruri Hiromi wrote:

> Let me know the keywords for finding threads about the "lightning
> round", if the discussion has began. I will move to the thread.
>=20
> For time table issue, will the discussion be held apart from v6ops or
> within v6ops? I am(or/and someone from Japan...) able to speak about
> Japanese situation and some findings.

Wes suggested one, and I suggested we start threads on the list as a =
"lightning round" - we can use face time to flesh those out in more =
detail. I have not seen threads on the list, unless you consider =
draft-gont-v6ops-ra-guard-evasion to be one. If you would like to start =
a topic thread, please feel free.

> But let me turn that around in a different way. Let's use this list as =
a "lightning round" for the coming two weeks. I'll invite emails of your =
proposed form - problem statement, brief explanation, why IETF =
can/should fix, and if obvious, a brief sketch of a possible fix.


Also, at IETF-80 we agreed that the agenda would be determined by =
traction - drafts posted (ideally long before the cutoff date) would be =
discussed face to face if they had traction on the list. In the survey I =
ran a few weeks ago, I had 22 respondents (not a large cross-section of =
a list of 1151), and it would be pretty easy to interpret the results as =
"westerners didn't generally respond; Chinese did."

I have had three requests for time from people who participated in the =
IPv6 Day and want to discuss what they saw; one of those may or may not =
be authorized by his company, and one of those may wind up part of =
Leslie Daigle's Tech Plenary discussion. We'll see what comes of those =
closer to the date.

I suspect that the agenda will therefore come down to the chair's views =
of what drafts and discussions have enjoyed supportive discussion on the =
list.=20

-00 draft cutoff is 4 July...=

From fred@cisco.com  Wed Jun 22 13:04:55 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026D711E8149; Wed, 22 Jun 2011 13:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.731
X-Spam-Level: 
X-Spam-Status: No, score=-110.731 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M46k1TRS+Q6l; Wed, 22 Jun 2011 13:04:53 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id A359711E813D; Wed, 22 Jun 2011 13:04:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1289; q=dns/txt; s=iport; t=1308773093; x=1309982693; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=QzSCD9FhBAFpB8tmd4lQ2e5l6m6ErB99p6FIsP4glNM=; b=hbcO5ciIdLvnsKNKYECjgRaiERMv4fYpAy7eZ/w5LMS59biW378tjwO4 LyYZVKenEsuZJ0NwoRjhx0HTovRso6PGkQk3A0D0/k5He3aB6oVWQabSX OZV/6y179Ceu1eE7eH+9jMm8NzkNLVJaB12BA97fnneDPr7RNKU7w/N/X c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAIVKAk6rRDoI/2dsb2JhbABTpxF3iHOiRp45hi0EhyWKRYRli0c
X-IronPort-AV: E=Sophos;i="4.65,407,1304294400"; d="scan'208";a="344358256"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 22 Jun 2011 20:04:53 +0000
Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5MK4jWQ024694; Wed, 22 Jun 2011 20:04:51 GMT
Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 22 Jun 2011 13:04:52 -0700
X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 22 Jun 2011 13:04:52 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
In-Reply-To: 
Date: Wed, 22 Jun 2011 13:04:35 -0700
Message-Id: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> 
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: ipv6@ietf.org, v6ops@ietf.org, RJ Atkinson 
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 20:04:55 -0000

On Jun 22, 2011, at 4:15 AM, Mikael Abrahamsson wrote:

> Just the same way that it's "obvious" that anyone can spoof RAs on a =
flat L2 lan, it's "obvious" that fragmentation and headers can make =
parsing actual payload harder and needs to be handled. These two =
"obvious" have historically been overlooked numerous times.

=46rom my perspective, the issue with the RA-Guard evasion draft isn't =
that the faults are possible or that they are described; it's that the =
description is specific to RA-Guard. In point of fact, these kinds of =
attacks are true for any kind of firewall or other middleware that has =
the notion of identifying a specific non-IP packet and selectively do =
something to it. I personally think the right way to approach this is to =
describe the attack and note, in a footnote somewhere, that one of the =
ten thousand special cases it applies to is RA Guard. Another one that =
it applies to is any case of deep packet inspection, a specific special =
case of that being Cleanfeed - anyone that thinks they can use deep =
packet inspection to eliminate pornography, Al-Queda literature, or dog =
racing should be advised that overcoming that is as simple as https or =
obscure fragmentation that splits a "GET" at a difficult place.=

From internet-drafts@ietf.org  Wed Jun 22 13:14:31 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A116B11E8161; Wed, 22 Jun 2011 13:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level: 
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw+0rC1nuu4K; Wed, 22 Jun 2011 13:14:30 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3A511E809C; Wed, 22 Jun 2011 13:14:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.55
Message-ID: <20110622201430.898.93688.idtracker@ietfa.amsl.com>
Date: Wed, 22 Jun 2011 13:14:30 -0700
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-advisory-02.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 20:14:31 -0000

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

	Title           : Advisory Guidelines for 6to4 Deployment
	Author(s)       : Brian Carpenter
	Filename        : draft-ietf-v6ops-6to4-advisory-02.txt
	Pages           : 21
	Date            : 2011-06-22

   This document provides advice to network operators about deployment
   of the 6to4 technique for automatic tunneling of IPv6 over IPv4.  It
   is principally addressed to Internet Service Providers, including
   those that do not yet support IPv6, and to Content Providers.  Some
   advice to implementers is also included.  The intention of the advice
   is to minimise both user dissatisfaction and help desk calls.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-advisory-02.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-advisory-02.txt

From Ted.Lemon@nominum.com  Wed Jun 22 13:19:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F5722800F; Wed, 22 Jun 2011 13:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level: 
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcX0mVRy1O92; Wed, 22 Jun 2011 13:19:09 -0700 (PDT)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) by ietfa.amsl.com (Postfix) with ESMTP id 686A3228006; Wed, 22 Jun 2011 13:19:07 -0700 (PDT)
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 ESMTPS id B3F0E19005C; Wed, 22 Jun 2011 13:19:06 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
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, 22 Jun 2011 13:18:54 -0700
MIME-Version: 1.0 (Apple Message framework v1237.1)
Content-Type: text/plain; charset="us-ascii"
From: Ted Lemon 
In-Reply-To: 
Date: Wed, 22 Jun 2011 16:18:50 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org> 
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.1237.1)
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 20:19:10 -0000

On Jun 22, 2011, at 7:41 AM, Mikael Abrahamsson wrote:
> I agree, that's the deployment model I advocate for hostile scenarios. =
Use DHCPv6 for stateful addressing, advertise default GW via RA, don't =
advertise any on-link prefix, and make sure hosts can't L2 communicate =
at all with each other by means of enforcement in switches (or just =
separate them into different L2 domains).

Huh.   If I had a choice between RA and multicast, I think I'd choose =
multicast.   When you have to utterly cripple your technology in order =
to continue using a protocol, I think it's time to ask whether or not =
the protocol you're using is the right protocol at all.


From brian.e.carpenter@gmail.com  Wed Jun 22 13:25:51 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C567911E80CC for ; Wed, 22 Jun 2011 13:25:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.515
X-Spam-Level: 
X-Spam-Status: No, score=-103.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyFZ5uEouJE3 for ; Wed, 22 Jun 2011 13:25:51 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E465011E810F for ; Wed, 22 Jun 2011 13:25:50 -0700 (PDT)
Received: by fxm15 with SMTP id 15so987563fxm.31 for ; Wed, 22 Jun 2011 13:25:50 -0700 (PDT)
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:subject:content-type:content-transfer-encoding; bh=GK5MJFK+AkaM/iH59UM/Y7MUHIgoJtUiXbxdGPFlS9E=; b=xCJ4mO2S64lj10B+yKt8qE07DwgyIMvk/+4M2z90o+1euWRuXUjdtUHY1CiABFzVyC G90WHaLa9gspda1SVJvCdPcNc0NW3WG/drktcficCZvfpO23wV4nFFHMT1x3N9V2M2D3 EuOQZLFRsnaHIX7YpN4ncw7eOViZ77I+6XHts=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=VEE/38w0diUaHSnCk+5F21U/1EPbyZCfDhcJ1dnbUNQ3b2LlqddN4yS+0Dwis08NDQ B04m5Wzc3uGdf18i1cTJursAmYHkknVuYSzeiqIrmC8jBKqGPkJzn6DU51PEtZD2D5mg JahpiPFdmwjVMJ6p4NgmjcmrImfnS028TvBDM=
Received: by 10.223.21.141 with SMTP id j13mr1385098fab.79.1308774349117; Wed, 22 Jun 2011 13:25:49 -0700 (PDT)
Received: from [10.255.25.96] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id g7sm545402fac.15.2011.06.22.13.25.47 (version=SSLv3 cipher=OTHER); Wed, 22 Jun 2011 13:25:48 -0700 (PDT)
Message-ID: <4E024FC5.2030308@gmail.com>
Date: Thu, 23 Jun 2011 08:25:41 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: IPv6 Operations 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-6to4-advisory-02.txt]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jun 2011 20:25:51 -0000

This update resolves some Last Call and IESG comments.
There was one typo in an example IPv4 address, and the
other changes were all editorial, not technical.

   Brian

-------- Original Message --------
Subject: I-D Action: draft-ietf-v6ops-6to4-advisory-02.txt
Date: Wed, 22 Jun 2011 13:14:30 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: v6ops@ietf.org

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           : Advisory Guidelines for 6to4 Deployment
	Author(s)       : Brian Carpenter
	Filename        : draft-ietf-v6ops-6to4-advisory-02.txt
	Pages           : 21
	Date            : 2011-06-22

   This document provides advice to network operators about deployment
   of the 6to4 technique for automatic tunneling of IPv6 over IPv4.  It
   is principally addressed to Internet Service Providers, including
   those that do not yet support IPv6, and to Content Providers.  Some
   advice to implementers is also included.  The intention of the advice
   is to minimise both user dissatisfaction and help desk calls.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-advisory-02.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-advisory-02.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


-- 
Regards
   Brian Carpenter



From ipng@69706e6720323030352d30312d31340a.nosense.org  Wed Jun 22 17:26:00 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD07C21F8473; Wed, 22 Jun 2011 17:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.035
X-Spam-Level: 
X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wORIxxoVLE8K; Wed, 22 Jun 2011 17:26:00 -0700 (PDT)
Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 3D31C21F8472; Wed, 22 Jun 2011 17:25:59 -0700 (PDT)
Received: from 219-90-231-100.ip.adam.com.au ([219.90.231.100] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QZXjz-0008LV-6c; Thu, 23 Jun 2011 09:55:51 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 52D9C3B33E; Thu, 23 Jun 2011 09:55:50 +0930 (CST)
Date: Thu, 23 Jun 2011 09:55:48 +0930
From: Mark Smith 
To: Ted Lemon 
Message-ID: <20110623095548.24d89d7f@opy.nosense.org>
In-Reply-To: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>  
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 00:26:01 -0000

Hi Ted,


On Wed, 22 Jun 2011 16:18:50 -0400
Ted Lemon  wrote:

> On Jun 22, 2011, at 7:41 AM, Mikael Abrahamsson wrote:
> > I agree, that's the deployment model I advocate for hostile scenarios. Use DHCPv6 for stateful addressing, advertise default GW via RA, don't advertise any on-link prefix, and make sure hosts can't L2 communicate at all with each other by means of enforcement in switches (or just separate them into different L2 domains).
> 
> Huh.   If I had a choice between RA and multicast, I think I'd choose multicast.   When you have to utterly cripple your technology in order to continue using a protocol, I think it's time to ask whether or not the protocol you're using is the right protocol at all.
> 

You're right, with Ethernet being the wrong protocol. An Ethernet LAN's
nature is peer-to-peer or full mesh - every attached node can send to
any other individual node, many other nodes, or all other nodes. For SPs
who want to bill for, and possibly control/sanitise their inter-customer
traffic, this link layer peer-to-peer nature is a problem.
Hub-and-spoke or point-to-point reachability is what they want. If it
is possible to enforce a hub-or-spoke topology on an Ethernet LAN by
preventing the 1-to-many or 1-to-any capability, in effect making it an
NBMA link-layer, or creating a point-to-point topology via VLANs, then
Ethernet is the best choice because it is both cheap and ubiquitous. 

Regards,
Mark.

From ipng@69706e6720323030352d30312d31340a.nosense.org  Wed Jun 22 17:29:06 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77BC11E808A; Wed, 22 Jun 2011 17:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG63oLdoy5NN; Wed, 22 Jun 2011 17:29:06 -0700 (PDT)
Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id D4B7E11E8071; Wed, 22 Jun 2011 17:29:05 -0700 (PDT)
Received: from 219-90-231-100.ip.adam.com.au ([219.90.231.100] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QZXn6-00009K-SK; Thu, 23 Jun 2011 09:59:05 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 90F733B33E; Thu, 23 Jun 2011 09:59:04 +0930 (CST)
Date: Thu, 23 Jun 2011 09:59:04 +0930
From: Mark Smith 
To: RJ Atkinson 
Message-ID: <20110623095904.554dc351@opy.nosense.org>
In-Reply-To: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org> 
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 00:29:06 -0000

Hi Ran,

On Wed, 22 Jun 2011 08:10:27 -0400
RJ Atkinson  wrote:

> 
> On 22  Jun 2011, at 07:34 , Mark Smith wrote:
> > It may be getting to the point where it'd probably be easier
> > to address these issues by taking away hosts' ability to multicast
> > to other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke
> > mode of LAN operation, allowing the designated routers to also
> > act as traffic sanitisers for on-link inter-host traffic.
> 
> That is possible; doing so would create a new and different set 
> of operational issues and implementation issues.  It isn't
> immediately obvious to me that the alternative set of issues would be 
> simpler/cheaper/easier than the issues Fernando's proposal raises.
> 

Part of what influenced my suggestion is that mechanisms to implement
these sorts of controls already exist in some layer 2 devices - the
private vlan feature and placing devices into specific VLANs based on
802.1x authentication. So for environments where rouge RAs are a
likelihood, some of these mechanisms, possibly with some necessary
changes or additions to IPv6 (e.g. DUD proxy) might be more a
more effective and more general "traffic sanitation" solution for all
ND based threats, including rogue RAs, spoofed ND NAs etc.

> Another more fundamental question is how much operational risk the 
> folks who deploy edge networks believe they have, and how much 
> operational risk those folks are comfortable with.  Some or many such 
> operational folks might find all of these concepts to have excessive 
> capital and operational expense for the perceived risk reduction.
> They might conclude that the "cure" is worse than the "disease".
> 

I completely agree, the security context definitely needs to be
considered. A drawback of making a change as fundamental as, for
example, prohibiting fragmentation in ND messages, is that it implies
that it is necessary in any and all contexts. That may not actually be
true.

In the contexts where rouge RAs are a likelihood (e.g. public wifi,
"IPoE" SP networks, etc.) rather than a rare accident , then some of the
other layer 2 traffic control mechanisms I mentioned are probably going
to be deployed. I wonder if their likely presence reduces the need to
make such fundamental changes to IPv6 as disabling fragmentation in ND.

With the relatively large number of subnets available in IPv6, up to a
point it is practical to have a single host-router pair in a subnet.
Once you do that, the only possible victims of these threats are the
host itself or the router it depends on for off-link reachability, and
those router consequences will or can be limited to the router's host
facing interface. These types of on-link threats have now been mitigated
or eliminated by individually quarantining each host and using their
own self-interest to control their behaviour.


Best regards,
Mark.

From Ted.Lemon@nominum.com  Wed Jun 22 17:57:00 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D2D21F852C; Wed, 22 Jun 2011 17:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.456
X-Spam-Level: 
X-Spam-Status: No, score=-106.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NT9jisWcGeAh; Wed, 22 Jun 2011 17:57:00 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7B26121F852B; Wed, 22 Jun 2011 17:56:59 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTgKPWiLAlY1yWMUKfoszIKcnaS0W94xL@postini.com; Wed, 22 Jun 2011 17:56:59 PDT
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 342C01B8581; Wed, 22 Jun 2011 17:56:58 -0700 (PDT)
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 ESMTPS id 14410190058; Wed, 22 Jun 2011 17:56:58 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
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, 22 Jun 2011 17:56:57 -0700
MIME-Version: 1.0 (Apple Message framework v1242)
Content-Type: text/plain; charset="us-ascii"
From: Ted Lemon 
In-Reply-To: <20110623095548.24d89d7f@opy.nosense.org>
Date: Wed, 22 Jun 2011 20:56:52 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>
To: Mark Smith 
X-Mailer: Apple Mail (2.1242)
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 00:57:00 -0000

On Jun 22, 2011, at 8:25 PM, Mark Smith wrote:
> You're right, with Ethernet being the wrong protocol.

Well, let's be clear here: Ethernet is apparently the wrong protocol =
*for you*.   You should be running 802.1x, not plain ethernet, because =
you have specific needs that make plain ethernet an inappropriate choice =
for you.

But that wasn't what I was talking about.   IPv6 has to work on =
ethernet.   IPv6 multicast is useful, and we (at least, some of us) want =
it to work.   The solution to the rogue RA problem is not to get rid of =
ethernet (or at least, so I claim).   Moreover, even supposing we could =
get rid of ethernet in the sense that you mean, that would simply paper =
over the problem, not solve it.   If we want a secure network, we have =
to use secure protocols.   Firewalls are a great second-level defense =
(and your hub-and-spoke model is basically a firewall).   But they do =
not make your network secure: they simply make it harder to attack.

So if in fact it is impossible for RA to be adequately secured on an =
ethernet, then we need to fix RA, or come up with a different solution, =
not slap a bandage on it and call it done.


From swmike@swm.pp.se  Wed Jun 22 22:48:38 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8E61F0C4A; Wed, 22 Jun 2011 22:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTwtSSQumrGU; Wed, 22 Jun 2011 22:48:38 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5451F0C4E; Wed, 22 Jun 2011 22:48:36 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id E97559C; Thu, 23 Jun 2011 07:48:32 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E5D529A; Thu, 23 Jun 2011 07:48:32 +0200 (CEST)
Date: Thu, 23 Jun 2011 07:48:32 +0200 (CEST)
From: Mikael Abrahamsson 
To: Ted Lemon 
In-Reply-To: 
Message-ID: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>  
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 05:48:38 -0000

On Wed, 22 Jun 2011, Ted Lemon wrote:

> On Jun 22, 2011, at 7:41 AM, Mikael Abrahamsson wrote:
>> I agree, that's the deployment model I advocate for hostile scenarios. Use DHCPv6 for stateful addressing, advertise default GW via RA, don't advertise any on-link prefix, and make sure hosts can't L2 communicate at all with each other by means of enforcement in switches (or just separate them into different L2 domains).
>
> Huh.  If I had a choice between RA and multicast, I think I'd choose 
> multicast.  When you have to utterly cripple your technology in order to 
> continue using a protocol, I think it's time to ask whether or not the 
> protocol you're using is the right protocol at all.

Could you please rephrase the above, I don't understand. Protocol?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From swmike@swm.pp.se  Wed Jun 22 23:34:08 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E58021F847A; Wed, 22 Jun 2011 23:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0oNwSMWADjy; Wed, 22 Jun 2011 23:34:08 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0B721F8453; Wed, 22 Jun 2011 23:34:07 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 417F09C; Thu, 23 Jun 2011 08:34:05 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3CE759A; Thu, 23 Jun 2011 08:34:05 +0200 (CEST)
Date: Thu, 23 Jun 2011 08:34:05 +0200 (CEST)
From: Mikael Abrahamsson 
To: Mark Smith 
In-Reply-To: <20110623095548.24d89d7f@opy.nosense.org>
Message-ID: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 06:34:08 -0000

On Thu, 23 Jun 2011, Mark Smith wrote:

> Hub-and-spoke or point-to-point reachability is what they want. If it is 
> possible to enforce a hub-or-spoke topology on an Ethernet LAN by 
> preventing the 1-to-many or 1-to-any capability, in effect making it an 
> NBMA link-layer, or creating a point-to-point topology via VLANs, then 
> Ethernet is the best choice because it is both cheap and ubiquitous.

Yes, this has been a very successful model for high speed residential 
connectivity (ETTH) the past 10 years.

And yes, you have to protect the users from each other, so they don't do 
MITM-attacks on each other. This requires some kind of limitation of 
traffic they can send to each other using L2, and full L2 isolation is of 
course the best.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From swmike@swm.pp.se  Wed Jun 22 23:36:27 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4281F0C4B; Wed, 22 Jun 2011 23:36:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sApzjP0CEWC0; Wed, 22 Jun 2011 23:36:27 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 2A18E1F0C4A; Wed, 22 Jun 2011 23:36:27 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 366AC9C; Thu, 23 Jun 2011 08:36:26 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 341929A; Thu, 23 Jun 2011 08:36:26 +0200 (CEST)
Date: Thu, 23 Jun 2011 08:36:26 +0200 (CEST)
From: Mikael Abrahamsson 
To: Ted Lemon 
In-Reply-To: 
Message-ID: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org> 
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 06:36:27 -0000

On Wed, 22 Jun 2011, Ted Lemon wrote:

> So if in fact it is impossible for RA to be adequately secured on an 
> ethernet, then we need to fix RA, or come up with a different solution, 
> not slap a bandage on it and call it done.

I don't see how it can be fixed. Short of encrypting all traffic and 
pre-distributing keys, ethernet can't be fixed without the "bandaids" you 
seem to call the measures being used widely to assure ethernet can in 
fact be used securely.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From v6ops@globis.net  Wed Jun 22 23:57:25 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105AB21F85A4; Wed, 22 Jun 2011 23:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level: 
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIz6IhlPKZU8; Wed, 22 Jun 2011 23:57:18 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 836FC21F8585; Wed, 22 Jun 2011 23:57:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7CE498700F0; Thu, 23 Jun 2011 08:56:45 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxNkGFhcEifx; Thu, 23 Jun 2011 08:56:40 +0200 (CEST)
Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 079878700EF; Thu, 23 Jun 2011 08:56:40 +0200 (CEST)
Message-ID: <4E02E3A7.4010100@globis.net>
Date: Thu, 23 Jun 2011 08:56:39 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: v6ops@ietf.org, ipv6@ietf.org, Ted Lemon 
Content-Type: multipart/alternative; boundary="------------040101040407070906050409"
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 06:57:25 -0000

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

>
> Subject:
> Re: [v6ops] Question regarding RA-Guard evasion (ND and extension 
> headers)
> From:
> Ted Lemon 
> Date:
> Wed, 22 Jun 2011 20:56:52 -0400
>
> To:
> Mark Smith 
> CC:
> v6ops@ietf.org, ipv6@ietf.org
>
> Content-Transfer-Encoding:
> quoted-printable
> Precedence:
> list
> MIME-Version:
> 1.0 (Apple Message framework v1242)
> References:
> <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> 
>  
> <20110622210451.60ad8bce@opy.nosense.org> 
>  
>  
> <20110623095548.24d89d7f@opy.nosense.org>
> In-Reply-To:
> <20110623095548.24d89d7f@opy.nosense.org>
> Message-ID:
> 
> Content-Type:
> text/plain; charset="us-ascii"
> Message:
> 7
>
>
> On Jun 22, 2011, at 8:25 PM, Mark Smith wrote:
>    
>> >  You're right, with Ethernet being the wrong protocol.
>>      
>
> Well, let's be clear here: Ethernet is apparently the wrong protocol*for you*.   You should be running 802.1x, not plain ethernet, because you have specific needs that make plain ethernet an inappropriate choice for you.
>
> But that wasn't what I was talking about.   IPv6 has to work on ethernet.   IPv6 multicast is useful, and we (at least, some of us) want it to work.   The solution to the rogue RA problem is not to get rid of ethernet (or at least, so I claim).   Moreover, even supposing we could get rid of ethernet in the sense that you mean, that would simply paper over the problem, not solve it.   If we want a secure network, we have to use secure protocols.   Firewalls are a great second-level defense (and your hub-and-spoke model is basically a firewall).   But they do not make your network secure: they simply make it harder to attack.
>
> So if in fact it is impossible for RA to be adequately secured on an ethernet, then we need to fix RA, or come up with a different solution, not slap a bandage on it and call it done.
>
>    

Sounds sensible.

Following are IMVVHO "requirements" from an operational perspective.

People have similar "issues" with ARP and DHCP (v4) and IPv4 today. But 
today it is also trivial to filter BOOTP on networks with fixed 
links/ports to make sure the default route and DNS server are set via 
DHCP, and only the designated DHCP server/ DHCP relay can/will reply, 
and that's generally been "good enough". For wireless, people are 
generally employing something else, like 802.1X, anyway.

Sometimes I think we're in danger of making things so complex that the 
simple filters will no longer work (and having to buy a complete new 
generation of Ethernet LAN switches to make RA work does not sound 
operationally attractive)

IMVHO If it was equally trivial as today to be able to completely filter 
the messages that set the default route and the DNS server to certain 
LAN ports or MAC addresses or IP source addresses or well-known port 
numbers, and so be able to fairly reliably set the DNS server and the 
default router on end hosts from a (weakly) trusted source, then the 
"issue" would be "solved" for most users, because that would be no 
different to today.

If people want to buy a new switch to implement RA Guard, then that's 
fine too. But RA Guard should not be a prerequisite for reliably setting 
of a default route on Ethernet, simply because corporate LAN switches 
generally have to last 5-10 years or so before being replaced.

If the trust relationship between an end node and the source that 
provides the configuration information on the default route and DNS 
server could be made even stronger, all the better, but in a World of 
roaming devices and guest users, that is not a trivial nut to crack 
operationally.

regards,
RayH

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










  

    
      

        
        
Subject:
        

Re: [v6ops] Question regarding RA-Guard evasion (ND and extension
headers)		
      

      

        
        
From: 

Ted Lemon <Ted.Lemon@nominum.com>		
      

      

        
        
Date: 

Wed, 22 Jun 2011 20:56:52 -0400		
      

    
  

  

    
      

        
        
To: 

Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>		
      

      

        
        
CC: 

v6ops@ietf.org, ipv6@ietf.org		
      

    
  

  

    
      

        
        
Content-Transfer-Encoding:
        

quoted-printable		
      

      

        
        
Precedence:
        

list		
      

      

        
        
MIME-Version:
        

1.0 (Apple Message framework v1242)		
      

      

        
        
References:
        

<282787FA-C418-430C-B473-152B4FFE900C@gmail.com>
<m1QZLSP-0001h8C@stereo.hq.phicoh.net>
<20110622210451.60ad8bce@opy.nosense.org>
<alpine.DEB.2.00.1106221337411.19581@uplift.swm.pp.se>
<CF7C688F-9262-4A6C-9B57-CFDDF94D246D@nominum.com>
<20110623095548.24d89d7f@opy.nosense.org>		
      

      

        
        
In-Reply-To:
        

<20110623095548.24d89d7f@opy.nosense.org>		
      

      

        
        
Message-ID:
        

<B5FBA399-6AAC-4036-A0D3-CAA546190B92@nominum.com>		
      

      

        
        
Content-Type:
        

text/plain; charset="us-ascii"		
      

      

        
        
Message:
        

7		
      

    
  

  

  

  
On Jun 22, 2011, at 8:25 PM, Mark Smith wrote:
  

  

    
> You're right, with Ethernet being the wrong protocol.
    

  

  

Well, let's be clear here: Ethernet is apparently the wrong protocol *for you*.   You should be running 802.1x, not plain ethernet, because you have specific needs that make plain ethernet an inappropriate choice for you.

But that wasn't what I was talking about.   IPv6 has to work on ethernet.   IPv6 multicast is useful, and we (at least, some of us) want it to work.   The solution to the rogue RA problem is not to get rid of ethernet (or at least, so I claim).   Moreover, even supposing we could get rid of ethernet in the sense that you mean, that would simply paper over the problem, not solve it.   If we want a secure network, we have to use secure protocols.   Firewalls are a great second-level defense (and your hub-and-spoke model is basically a firewall).   But they do not make your network secure: they simply make it harder to attack.

So if in fact it is impossible for RA to be adequately secured on an ethernet, then we need to fix RA, or come up with a different solution, not slap a bandage on it and call it done.

  

  





Sounds sensible.



Following are IMVVHO "requirements" from an operational perspective.



People have similar "issues" with ARP and DHCP (v4) and IPv4 today. But
today it is also trivial to filter BOOTP on networks with fixed
links/ports to make sure the default route and DNS server are set via
DHCP, and only the designated DHCP server/ DHCP relay can/will reply,
and that's generally been "good enough". For wireless, people are
generally employing something else, like 802.1X, anyway.



Sometimes I think we're in danger of making things so complex that the
simple filters will no longer work (and having to buy a complete new
generation of Ethernet LAN switches to make RA work does not sound
operationally attractive)



IMVHO If it was equally trivial as today to be able to completely
filter the messages that set the default route and the DNS server to
certain LAN ports or MAC addresses or IP source addresses or well-known
port numbers, and so be able to fairly reliably set the DNS server and
the default router on end hosts from a (weakly) trusted source, then
the "issue" would be "solved" for most users, because that would be no
different to today.



If people want to buy a new switch to implement RA Guard, then that's
fine too. But RA Guard should not be a prerequisite for reliably
setting of a default route on Ethernet, simply because corporate LAN
switches generally have to last 5-10 years or so before being replaced.



If the trust relationship between an end node and the source that
provides the configuration information on the default route and DNS
server could be made even stronger, all the better, but in a World of
roaming devices and guest users, that is not a trivial nut to crack
operationally.



regards,

RayH




--------------040101040407070906050409--

From swmike@swm.pp.se  Thu Jun 23 00:03:39 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824CD21F85B7; Thu, 23 Jun 2011 00:03:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShIoX+C5V9KL; Thu, 23 Jun 2011 00:03:39 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id B657C21F85B6; Thu, 23 Jun 2011 00:03:38 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 981539C; Thu, 23 Jun 2011 09:03:37 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 95C719A; Thu, 23 Jun 2011 09:03:37 +0200 (CEST)
Date: Thu, 23 Jun 2011 09:03:37 +0200 (CEST)
From: Mikael Abrahamsson 
To: Ray Hunter 
In-Reply-To: <4E02E3A7.4010100@globis.net>
Message-ID: 
References: <4E02E3A7.4010100@globis.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 07:03:39 -0000

On Thu, 23 Jun 2011, Ray Hunter wrote:

> too. But RA Guard should not be a prerequisite for reliably setting of a 
> default route on Ethernet, simply because corporate LAN switches generally 
> have to last 5-10 years or so before being replaced.

I don't see 5-10 year old LAN switches having any kind of capability of 
filtering just certain IPv6 packets. They might have the possibility of 
filtering all 0x86dd packet which is the sensible thing to do unless one 
can secure it by other means.

Securing L2 networks is something not generally done today in enterprise 
and surprisingly often in SP environments as well. This can be seen by all 
the problems reported by Windows ICS v6 RA:s being sent out and causing 
problems to other users (which in a properly build network it shouldn't 
have the capability of doing, because those packets should be filtered by 
the access network).

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From tjc@ecs.soton.ac.uk  Thu Jun 23 02:37:48 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A2321F8560; Thu, 23 Jun 2011 02:37:48 -0700 (PDT)
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_21=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcHpvpBR-Ukk; Thu, 23 Jun 2011 02:37:47 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEE421F8563; Thu, 23 Jun 2011 02:37:46 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5N9bf1M017317;  Thu, 23 Jun 2011 10:37:41 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p5N9bf1M017317
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1308821861; bh=HnGC1uEFJBqocYHs5o5yFpNdZcM=; h=References:In-Reply-To:Mime-Version:From:Subject:Date:To; b=kMbcAU6VOXw3gbLZseDzS/wEHQGaeQKJhxY5VEHuiCkyDNLhc3ByrIXTCkQZ7Wn4C T14E77rg7lRtqm+/X9jCrDEXz6B9CwRAfcdLUuAmmdb7ZmJrLTUWAuXK+Mwloz7QEh DhmtZEeyvns8EXK6ufbhuDkOGhUYj6ROgEU1ouAQ=
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 n5MAbf0366136384Li ret-id none; Thu, 23 Jun 2011 10:37:41 +0100
Received: from cerf.ecs.soton.ac.uk (cerf.ecs.soton.ac.uk [152.78.69.39]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5N9bZQb004226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Jun 2011 10:37:35 +0100
References: <4E02E3A7.4010100@globis.net>  <88193BC0-9F0B-4D39-B770-81B4ECF39666@ecs.soton.ac.uk>
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-ID: 
Content-Transfer-Encoding: quoted-printable
From: Tim Chown 
Date: Thu, 23 Jun 2011 10:37:34 +0100
To: v6ops@ietf.org, ipv6@ietf.org
X-Mailer: Apple Mail (2.1084)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=n5MAbf036613638400; tid=n5MAbf0366136384Li; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: p5N9bf1M017317
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 09:37:48 -0000

On 23 Jun 2011, at 08:03, Mikael Abrahamsson wrote:

> Securing L2 networks is something not generally done today in =
enterprise and surprisingly often in SP environments as well. This can =
be seen by all the problems reported by Windows ICS v6 RA:s being sent =
out and causing problems to other users (which in a properly build =
network it shouldn't have the capability of doing, because those packets =
should be filtered by the access network).

I think there is some effort to secure layer 2 in academic enterprises, =
e.g. I did a straw poll at a recent UK event and about 2/3rds of the =
admins there were using DHCPv4 snooping/filtering on layer 2 devices.  =
But pretty much none had any filters applied for RAs, even if they =
could.   This probably explains in part why so many admins are =
'comfortable' with the idea of DHCPv6-only operation, in that it's a =
known risk model.

Some mechanisms also don't help in the way they're deployed.  While =
academic sites are now heavily into 802.1X for eduroam deployment, =
pretty much every rogue ICS-a-like RA that's seen is issued by a device =
that has authenticated using 802.1X, but in almost every case the =
devices are put into a shared VLAN, not one per user/device.

But ICS-a-like rogue RAs are invariably 6to4 prefix, and RFC3484-bis =
generally handles that.  And such 'accidental' rogue RAs are very =
unlikely to be fragmented in an attempt to defeat RA-Guard.   RFC6104 =
was written with accidental RAs in mind, for reasons stated in the text.

Interestingly I've noticed a few scenarios where unicast RAs are being =
suggested more, e.g. related to wireless roaming on campuses.

Tim


From Fred.L.Templin@boeing.com  Thu Jun 23 10:03:55 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EFF11E816B for ; Thu, 23 Jun 2011 10:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.135
X-Spam-Level: 
X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoPDdFhsH45I for ; Thu, 23 Jun 2011 10:03:54 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id DC9DA11E8160 for ; Thu, 23 Jun 2011 10:03:54 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5NH3tPw023909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 23 Jun 2011 10:03:56 -0700 (PDT)
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 p5NH3rrc021423 for ; Thu, 23 Jun 2011 12:03:53 -0500 (CDT)
Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5NH3p4h021334 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Thu, 23 Jun 2011 12:03:52 -0500 (CDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Thu, 23 Jun 2011 10:03:51 -0700
From: "Templin, Fred L" 
To: "v6ops@ietf.org" 
Date: Thu, 23 Jun 2011 10:03:49 -0700
Thread-Topic: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?
Thread-Index: AcwtJ7+vRpD6lZYVTg2di+8xEeOXSwDxF7swADaj18A=
Message-ID: 
References:  <31BCF9EC-7A49-4C5B-B62A-CAECF66F23F1@bogus.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
Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 17:03:55 -0000

FYI, I just posted a -11 update to this document. The
update includes the reference to RFC3068 per Joel's
recommendation, and also adds a new section on "Manual
Configuration". See below for the announcement:
=20
Thanks - Fred
fred.l.templin@boeing.com
=20
------
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

	Title           : Operational Guidance for IPv6 Deployment in IPv4 Sites u=
sing ISATAP
	Author(s)       : Fred L. Templin
	Filename        : draft-templin-v6ops-isops-11.txt
	Pages           : 27
	Date            : 2011-06-23

   Many end user sites in the Internet today still have predominantly
   IPv4 internal infrastructures.  These sites range in size from small
   home/office networks to large corporate enterprise networks, but
   share the commonality that IPv4 continues to provide satisfactory
   internal routing and addressing services for most applications.  As
   more and more IPv6-only services are deployed in the Internet,
   however, end user devices within such sites will increasingly require
   at least basic IPv6 functionality for external access.  It is also
   expected that more and more IPv6-only devices will be deployed within
   the site over time.  This document therefore provides operational
   guidance for deployment of IPv6 within predominantly IPv4 sites using
   the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-templin-v6ops-isops-11.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-templin-v6ops-isops-11.txt


________________________________

	From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Templin, Fred L
	Sent: Wednesday, June 22, 2011 8:13 AM
	To: Joel Jaeggli
	Cc: v6ops@ietf.org
	Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?
=09
=09
	Hi Joel,
	=20
	Thanks for your comments, and see below for responses:


________________________________

		From: Joel Jaeggli [mailto:joelja@bogus.com]=20
		Sent: Friday, June 17, 2011 12:50 PM
		To: Templin, Fred L
		Cc: v6ops@ietf.org
		Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?
	=09
	=09
		On Jun 3, 2011, at 8:13 AM, Templin, Fred L wrote:


			Hello,
		=09
			Significant improvements have been made to this document
			(below) based on comments received and new observations.
			IMHO, this is an important document for enabling transition
			to IPv6 within IPv4 sites; hence, I would like to call for
			working group adoption at this time.
		=09
			Thanks - Fred
			fred.l.templin@boeing.com
		=09
		=09


		Replying to this message as a way to maintain the threading. these notes =
are relative to the current version of the draft which I reviewed last week=
:

		http://tools.ietf.org/html/draft-templin-v6ops-isops-10

		So I tried for a while to separate the operational advice that could be a=
pplied to my 2005 era knowledge of isatap and there's  quite a few things t=
hat jive with that (tunnel loops for example).=20

	OK. =20

		In other cases such isatap dhcpv6 (4.5) I'm a bit-off in the weeds, what =
implementations are capable of doing that? Are we recommending that they do=
 it? do they already?=20

	I can't speak for current implementations, but the DHCPv6 approach is
	based on the fact that address and prefix assignment on IPv6 interfaces
	are seperable functions. IPv6 prefixes assigned to ISATAP interfaces can
	only be used for autoconfiguration of ISATAP addresses and not ordinary
	IPv6 addresses. However, an ordinary IPv6 address can be assigned to
	an ISATAP interface the same as for any other IPv6 interface as long as
	it is not covered by a prefix assigned to the interface.

				Regarding aero (section 4.6) that looks pretty much like new work or an=
 extension to the specification.=20

	AERO is a new but backwards-compatible method of doing redirection
	of an on-link neighbor to another on-link neighbor. However, ISATAP
	interfaces can still use standards ICMPv6 Redirect messages the same
	as for any IPv6 interface. Advertising ISATAP routers should only send
	ICMPv6 redirects when they are certain that the redirected ISATAP node
	can tunnel packets directly to the target of the redirect, however. Perhap=
s
	a few more words saying explicitly that standards ICMPv6 redirects are
	still supported would help?=20

		Are there participants with extant isatap deployements or host implementa=
tions or knowledge fresher than mine that would care to comment on this dra=
ft.=20
		=20

	There are certainly vendors who are shipping ISATAP in their products
	today. Perhaps they can comment.=20

		section 9 alternative approaches, there's some consensus that rfc 3056 wa=
s never really deployed so the reference to 6to4 should probably be to 3068=
=20
		=20

	OK - I can fix this.
	=20
	Thanks - Fred
	fred.l.templin@boeing.com


From v6ops@globis.net  Thu Jun 23 10:14:48 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F2511E8160; Thu, 23 Jun 2011 10:14:48 -0700 (PDT)
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_21=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w87TukcSPWS; Thu, 23 Jun 2011 10:14:47 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id E027A11E8125; Thu, 23 Jun 2011 10:14:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id AC74E870087; Thu, 23 Jun 2011 19:14:15 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQX8cWYtPO0T; Thu, 23 Jun 2011 19:14:10 +0200 (CEST)
Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 61A61870079; Thu, 23 Jun 2011 19:14:10 +0200 (CEST)
Message-ID: <4E037462.3070601@globis.net>
Date: Thu, 23 Jun 2011 19:14:10 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Mikael Abrahamsson 
References: <4E02E3A7.4010100@globis.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 17:14:48 -0000

Mikael Abrahamsson wrote:
> On Thu, 23 Jun 2011, Ray Hunter wrote:
>
>> too. But RA Guard should not be a prerequisite for reliably setting 
>> of a default route on Ethernet, simply because corporate LAN switches 
>> generally have to last 5-10 years or so before being replaced. 
>
> I don't see 5-10 year old LAN switches having any kind of capability 
> of filtering just certain IPv6 packets. They might have the 
> possibility of filtering all 0x86dd packet which is the sensible thing 
> to do unless one can secure it by other means.
>
> Securing L2 networks is something not generally done today in 
> enterprise and surprisingly often in SP environments as well. This can 
> be seen by all the problems reported by Windows ICS v6 RA:s being sent 
> out and causing problems to other users (which in a properly build 
> network it shouldn't have the capability of doing, because those 
> packets should be filtered by the access network). 
Many current devices implement DHCP snooping, IP source guard, and 
similar ARP inspection filters for DHCP (v4) (as an alternative to 
802.1x) because the user admin associated with L2 security technology is 
generally a heavy operational burden. I don't have figures for the 
percentage of people who would be affected by losing such equivalent 
functionality if they moved to IPv6 today, but presumably there was an 
operational "need", or else these IPv4 features would not have been 
implemented. Obviously the likes of 802.1X are technologically far 
superior, but that isn't always the deciding factor for implementation.

I can guess the answer the CFO will give those same people if they 
request to renew their current L2 switches 5 years early just because 
they need to implement RA Guard.

So what would those people do today to retain similar functionality for 
IPv6 without investing heavily, or switching off IPv6?

 > Short of encrypting all traffic and pre-distributing keys

If the WG has reached a stage of looking for a potential alternative 
mitigation (and perhaps completely crazy out of the box thinking) that 
doesn't involve replacing switches, may I humbly suggest consideration 
of using the current DHCPv4/bootp mechanism to distribute an IPv6 
address and MAC address (or some other stronger public-key) associated 
with one or more trusted default routers in the initial network booting 
process as a mitigation mechanism/ stop gap? The IPv6 hosts can then 
defend themselves by filtering incoming RA messages to be from the 
trusted source. I know it sounds truly awful, but it might work. IPv4 
RFC1918 addresses are not going to run out. And it seems to me that's 
the gap between DHCPv6 and DHCPv4 if you have a "problem" with rogue RA, 
but you already have a decent solution in place for "secure enough" 
DHCPv4 and DHCPv6. After all, IPv4 transport was also deemed acceptable 
for use in resolving IPv6 AAAA records. If this is too far left field, 
please simply ignore me :) Or better still, propose something smarter ;)

regards,
RayH

From nxdc38@motorola.com  Thu Jun 23 12:46:06 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD3A21F8485 for ; Thu, 23 Jun 2011 12:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level: 
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRJDzqBnI57S for ; Thu, 23 Jun 2011 12:46:05 -0700 (PDT)
Received: from exprod5og104.obsmtp.com (exprod5og104.obsmtp.com [64.18.0.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB5B21F8483 for ; Thu, 23 Jun 2011 12:46:05 -0700 (PDT)
Received: from il93mgrg01.am.mot-mobility.com ([144.188.21.13]) (using TLSv1) by exprod5ob104.postini.com ([64.18.4.12]) with SMTP ID DSNKTgOX/G+DyO4xoX9mlAr0o5tgphQrU1T3@postini.com; Thu, 23 Jun 2011 12:46:05 PDT
Received: from il93mgrg01.am.mot-mobility.com ([10.22.94.168]) by il93mgrg01.am.mot-mobility.com (8.14.3/8.14.3) with ESMTP id p5NJhCum024666 for ; Thu, 23 Jun 2011 15:43:13 -0400 (EDT)
Received: from mail-gx0-f170.google.com (mail-gx0-f170.google.com [209.85.161.170]) by il93mgrg01.am.mot-mobility.com (8.14.3/8.14.3) with ESMTP id p5NJgHIX024221 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 23 Jun 2011 15:43:12 -0400 (EDT)
Received: by mail-gx0-f170.google.com with SMTP id 27so1339804gxk.15 for ; Thu, 23 Jun 2011 12:46:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.236.161.228 with SMTP id w64mr3573180yhk.140.1308858363309; Thu, 23 Jun 2011 12:46:03 -0700 (PDT)
Received: by 10.147.172.7 with HTTP; Thu, 23 Jun 2011 12:46:03 -0700 (PDT)
Date: Thu, 23 Jun 2011 15:46:03 -0400
Message-ID: 
From: Piotr Galecki 
To: v6ops@ietf.org
Content-Type: multipart/alternative; boundary=20cf3056388bce6f7204a66655a3
X-CFilter-Loop: Reflected
Subject: [v6ops] "ipDefaultRouterTable" in IP-MIB (RFC 4293)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 19:47:40 -0000

--20cf3056388bce6f7204a66655a3
Content-Type: text/plain; charset=ISO-8859-1

Could someone on this list confirm my thinking regarding the
ipDefaultRouterTable?

The RFC 4293 states that ipDefaultRouterTable should be supported for both
hosts and routers.
" Both the ipv6ScopeZoneIndexTable and ipDefaultRouterTable are required on
all IPv6 entities. "

However it is not clear to me what exactly this table should contain on a
router.
The terminology Default Router is usually used in the host context.

Should this table contain a list of routers which are used as next hops of
the default route?
What should the ipDefaultRouterLifetime be set to if default route is
provisioned statically or using IS-ISv6, no RA?

Thanks,
Piotr

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

Could someone on this list confirm my thinking regarding the ipDefaultRoute=
rTable?

The RFC 4293 states that ipDefaultRouterTable =
should be supported for both hosts and routers.
" Both the ipv6Scop=
eZoneIndexTable and ipDefaultRouterTable are required on all IPv6 entities.=
 "


However it is not clear to me what exactly this table should contain on=
 a router.
The terminology Default Router is usually used in the host co=
ntext.

Should this table contain a list of routers which are used as=
 next hops of the default route?

What should the ipDefaultRouterLifetime be set to if default route is provi=
sioned statically or using IS-ISv6, no RA?

Thanks,
Piotr



--20cf3056388bce6f7204a66655a3--

From Ted.Lemon@nominum.com  Thu Jun 23 13:30:50 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818B121F850A; Thu, 23 Jun 2011 13:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.466
X-Spam-Level: 
X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOO2i6Ix4wcF; Thu, 23 Jun 2011 13:30:49 -0700 (PDT)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 71D7A21F84AC; Thu, 23 Jun 2011 13:30:49 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTgOieE6rAV8QgUsfB54Lkttfbwgz7gou@postini.com; Thu, 23 Jun 2011 13:30:49 PDT
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 75CE61B84A0; Thu, 23 Jun 2011 13:30:48 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 684D919005C; Thu, 23 Jun 2011 13:30:48 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from exchange-01.WIN.NOMINUM.COM (64.89.228.50) by CAS-02.WIN.NOMINUM.COM (64.89.228.132) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 23 Jun 2011 13:30:42 -0700
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; Thu, 23 Jun 2011 13:30:41 -0700
MIME-Version: 1.0 (Apple Message framework v1242)
Content-Type: text/plain; charset="us-ascii"
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 23 Jun 2011 16:30:37 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <63524B72-6890-48E4-926F-030744B415A2@nominum.com>
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>  
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.1242)
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 20:30:50 -0000

On Jun 23, 2011, at 2:36 AM, Mikael Abrahamsson wrote:
> I don't see how it can be fixed. Short of encrypting all traffic and =
pre-distributing keys, ethernet can't be fixed without the "bandaids" =
you seem to call the measures being used widely to assure ethernet can =
in fact be used securely.

There probably is no single solution.   But let's consider the solution =
Mark proposed: use the fact that you control the infrastructure to =
control the flow of packets on the network in such a way that rogue RAs =
cannot reach leaf nodes.   The reason I object to this solution, in =
addition to the fact that it breaks multicast, is that it's a firewall =
solution: the client doesn't know it's safe, and as soon as it connects =
to a network that's not protected in this way, it's vulnerable.   But =
the model of using infrastructure control as a credential is =
interesting.

Is there a way that someone who is not running 802.1x can demonstrate =
that they control layer 2?   It seems to me that for most examples of =
Layer 2 that we care about, the answer is probably yes.   So then if the =
secure link to the router can be used to communicate a secret, and the =
network can provide that secret back to the user in a way that a rogue =
RA agent could not do, then the end node can discriminate between rogue =
RAs and legitimate RAs.

E.g., suppose we have a WiFi network secured with WPA.   WPA uses an =
X.509 cert to establish the identity of the WPA server.   If the private =
key authenticated by the cert is used to sign the secret the client =
provides, then the client can be sure that the router it is talking to =
is controlled by the same entity that controls WPA.   Since WPA is tied =
directly to the infrastructure, that's proof that the router is managed =
by the infrastructure provider.
=20
Another solution that would work well in the case of frequently-visited =
networks would be the model that ssh uses: keep a list of good routers.  =
 When you connect to a wire, prefer routers on the "good" list to new =
routers.   If no RAs come from routers on the "good" list, then you need =
a heuristic to decide whether or not a new router is good.   The =
mechanism I described in the previous paragraph could be used to handle =
some exceptional cases; other heuristics could be used to handle cases =
where the link is not secured in any way: if I try to establish secure =
connections, and those connections turn out to be exposed to MITM =
attacks, then the router (and hence, the RA from that router) are not =
trustworthy.

The problem with this stuff is not that it's impossible.   It's that =
it's not simple.   If you want your communications to be secure, you =
have to secure them.   If all your communications are secure, then a =
rogue RA can only do two things: deny service, or allow an attacker to =
do traffic analysis and/or cryptanalysis that would not otherwise be =
possible.


From albert.e.manfredi@boeing.com  Thu Jun 23 13:40:35 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93ED321F8442; Thu, 23 Jun 2011 13:40:35 -0700 (PDT)
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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DxP1OoLCzf0; Thu, 23 Jun 2011 13:40:34 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id BBD9F21F8441; Thu, 23 Jun 2011 13:40:34 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5NKePWN010005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Jun 2011 13:40:26 -0700 (PDT)
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 p5NKePw7007415; Thu, 23 Jun 2011 15:40:25 -0500 (CDT)
Received: from XCH-MWHT-03.mw.nos.boeing.com (xch-mwht-03.mw.nos.boeing.com [134.57.119.161]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5NKeIfi007229 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 23 Jun 2011 15:40:23 -0500 (CDT)
Received: from XCH-MWPFX-01.mw.nos.boeing.com (132.173.24.10) by XCH-MWHT-03.mw.nos.boeing.com (134.57.119.161) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 23 Jun 2011 15:40:18 -0500
Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.118.180]) by XCH-MWPFX-01.mw.nos.boeing.com ([132.173.24.10]) with mapi; Thu, 23 Jun 2011 15:40:17 -0500
From: "Manfredi, Albert E" 
To: Ted Lemon 
Date: Thu, 23 Jun 2011 15:40:12 -0500
Thread-Topic: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
Thread-Index: Acwx5H+3fTxU6Ru8TdaKVw/1a7H8agAALFYA
Message-ID: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>   <63524B72-6890-48E4-926F-030744B415A2@nominum.com>
In-Reply-To: <63524B72-6890-48E4-926F-030744B415A2@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
X-TM-AS-Product-Ver: SMEX-10.0.0.1412-6.500.1024-18218.000
X-TM-AS-Result: No--21.977600-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 23 Jun 2011 13:53:59 -0700
Cc: "v6ops@ietf.org" , "ipv6@ietf.org" 
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension	headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 20:40:35 -0000

Ted Lemon wrote:

> There probably is no single solution.   But let's consider the solution
> Mark proposed: use the fact that you control the infrastructure to
> control the flow of packets on the network in such a way that rogue RAs
> cannot reach leaf nodes.   The reason I object to this solution, in
> addition to the fact that it breaks multicast, is that it's a firewall
> solution: the client doesn't know it's safe, and as soon as it connects
> to a network that's not protected in this way, it's vulnerable.   But
> the model of using infrastructure control as a credential is
> interesting.

While I too find it hard to accept the ETTH solution as being "real" Ethern=
et, I believe it is the network that is trying to protect itself here, more=
 than altruistic protection of clients. If clients are protected as a resul=
t, great.

Yes, in another network, those same clients might not be protected at all.

Your solutions appear to be more client-oriented.

Bert


From Ted.Lemon@nominum.com  Thu Jun 23 14:25:35 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F34C11E81AB; Thu, 23 Jun 2011 14:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.474
X-Spam-Level: 
X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92PJnPxctE-O; Thu, 23 Jun 2011 14:25:35 -0700 (PDT)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id CBDF611E81A1; Thu, 23 Jun 2011 14:25:34 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTgOvTWeWfUOt1QR7eQAunpMWjQ7jy7xv@postini.com; Thu, 23 Jun 2011 14:25:34 PDT
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 8CDB71B8536; Thu, 23 Jun 2011 14:25:33 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7DBE519005C; Thu, 23 Jun 2011 14:25:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from exchange-01.WIN.NOMINUM.COM (64.89.228.50) by CAS-01.WIN.NOMINUM.COM (64.89.228.131) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 23 Jun 2011 14:25:27 -0700
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; Thu, 23 Jun 2011 14:25:27 -0700
MIME-Version: 1.0 (Apple Message framework v1242)
Content-Type: text/plain; charset="us-ascii"
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 23 Jun 2011 17:25:23 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>   <63524B72-6890-48E4-926F-030744B415A2@nominum.com> 
To: "Manfredi, Albert E" 
X-Mailer: Apple Mail (2.1242)
Cc: "v6ops@ietf.org" , "ipv6@ietf.org" 
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension	headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 21:25:35 -0000

On Jun 23, 2011, at 4:40 PM, Manfredi, Albert E wrote:
> Your solutions appear to be more client-oriented.

That's correct.   Ultimately the security of the client depends on the =
client being secure.   Trying to secure the client by securing the =
network is a noble cause, but ultimately doomed to failure, because you =
can't control what networks the client connects to.   Of course there =
are special cases where this isn't true, but as mobile nodes get more =
and more capable, the set of all such special cases gets smaller and =
smaller.


From albert.e.manfredi@boeing.com  Thu Jun 23 14:31:15 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA37A11E8199; Thu, 23 Jun 2011 14:31:15 -0700 (PDT)
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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLd-pOicl25u; Thu, 23 Jun 2011 14:31:15 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 07D2111E81B6; Thu, 23 Jun 2011 14:31:15 -0700 (PDT)
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 p5NLV9aI017765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Jun 2011 14:31:12 -0700 (PDT)
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 p5NLV9op001665; Thu, 23 Jun 2011 14:31:09 -0700 (PDT)
Received: from XCH-MWHT-06.mw.nos.boeing.com (xch-mwht-06.mw.nos.boeing.com [134.57.113.166]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5NLV8em001611 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 23 Jun 2011 14:31:09 -0700 (PDT)
Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.118.180]) by XCH-MWHT-06.mw.nos.boeing.com ([134.57.113.166]) with mapi; Thu, 23 Jun 2011 16:31:08 -0500
From: "Manfredi, Albert E" 
To: Ted Lemon 
Date: Thu, 23 Jun 2011 16:31:07 -0500
Thread-Topic: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
Thread-Index: Acwx7BmJC20WsiiNQS2sTIswF0EhqAAAGs7g
Message-ID: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>   <63524B72-6890-48E4-926F-030744B415A2@nominum.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
x-tm-as-product-ver: SMEX-10.0.0.1412-6.500.1024-18218.000
x-tm-as-result: No--49.230000-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , "ipv6@ietf.org" 
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension	headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 21:31:16 -0000

Ted Lemon wrote:

> That's correct.   Ultimately the security of the client depends on the
> client being secure.   Trying to secure the client by securing the
> network is a noble cause, but ultimately doomed to failure, because you
> can't control what networks the client connects to.

No, I think you have it backwards.

It is service providers that are interested in protecting their networks, i=
n this discussion. If they also happen to protect their clients, that is ju=
st a nice byproduct.

Service providers want to keep malicious clients from degrading their netwo=
rk.

Bert


From Ted.Lemon@nominum.com  Thu Jun 23 14:56:58 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4FB21F852C; Thu, 23 Jun 2011 14:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.481
X-Spam-Level: 
X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sihXu40sLSS3; Thu, 23 Jun 2011 14:56:58 -0700 (PDT)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 1150E21F852B; Thu, 23 Jun 2011 14:56:54 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTgO2pUb2NRWGJ12OakGPiWmQArKj2eSy@postini.com; Thu, 23 Jun 2011 14:56:57 PDT
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 59DF9F8033; Thu, 23 Jun 2011 14:56:53 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4C2FE19005C; Thu, 23 Jun 2011 14:56:53 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from exchange-01.WIN.NOMINUM.COM (64.89.228.50) by CAS-01.WIN.NOMINUM.COM (64.89.228.131) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 23 Jun 2011 14:56:53 -0700
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; Thu, 23 Jun 2011 14:56:51 -0700
MIME-Version: 1.0 (Apple Message framework v1242)
Content-Type: text/plain; charset="us-ascii"
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 23 Jun 2011 17:56:47 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <8F573F95-319F-4DC2-8D07-59C431E0E65E@nominum.com>
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>   <63524B72-6890-48E4-926F-030744B415A2@nominum.com>   
To: "Manfredi, Albert E" 
X-Mailer: Apple Mail (2.1242)
Cc: "v6ops@ietf.org" , "ipv6@ietf.org" 
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension	headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 21:56:58 -0000

On Jun 23, 2011, at 5:31 PM, Manfredi, Albert E wrote:
> It is service providers that are interested in protecting their =
networks, in this discussion. If they also happen to protect their =
clients, that is just a nice byproduct.

That's fine for service providers, but service providers are not the =
only interested parties here.   Mark's solution does fine for that use =
case, but I would not want it on my home network.


From pch-b2B3A6689@u-1.phicoh.com  Thu Jun 23 15:08:33 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15E811E8086; Thu, 23 Jun 2011 15:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.539
X-Spam-Level: 
X-Spam-Status: No, score=-8.539 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWWHRjXsJE18; Thu, 23 Jun 2011 15:08:33 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id BA99A11E80D7; Thu, 23 Jun 2011 15:08:31 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QZs4b-0001glC; Fri, 24 Jun 2011 00:08:29 +0200
Message-Id: 
To: Ted Lemon 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>   <63524B72-6890-48E4-926F-030744B415A2@nominum.com>    <8F573F95-319F-4DC2-8D07-59C431E0E65E@nominum.com> 
In-reply-to: Your message of "Thu, 23 Jun 2011 17:56:47 -0400 ." <8F573F95-319F-4DC2-8D07-59C431E0E65E@nominum.com> 
Date: Fri, 24 Jun 2011 00:08:12 +0200
Cc: "v6ops@ietf.org" , "ipv6@ietf.org" 
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 22:08:34 -0000

In your letter dated Thu, 23 Jun 2011 17:56:47 -0400 you wrote:
>On Jun 23, 2011, at 5:31 PM, Manfredi, Albert E wrote:
>> It is service providers that are interested in protecting their networks, in
> this discussion. If they also happen to protect their clients, that is just a
> nice byproduct.
>
>That's fine for service providers, but service providers are not the only inte
>rested parties here.   Mark's solution does fine for that use case, but I woul
>d not want it on my home network.

Ideally, clients use end-to-end crypto to keep themselves secure, but the
network still has to be protected against denial of service attacks.


From Ted.Lemon@nominum.com  Thu Jun 23 15:14:14 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A8711E8125; Thu, 23 Jun 2011 15:14:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.488
X-Spam-Level: 
X-Spam-Status: No, score=-106.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkzlymOAeOGJ; Thu, 23 Jun 2011 15:14:13 -0700 (PDT)
Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 35E5811E80E1; Thu, 23 Jun 2011 15:14:13 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTgO6tNO6lmwm0TJDO6AvineY78crNU//@postini.com; Thu, 23 Jun 2011 15:14:13 PDT
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 1389D1B8576; Thu, 23 Jun 2011 15:14:12 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 051E619005C; Thu, 23 Jun 2011 15:14:12 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from exchange-01.WIN.NOMINUM.COM (64.89.228.50) by CAS-02.WIN.NOMINUM.COM (64.89.228.132) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 23 Jun 2011 15:13:36 -0700
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; Thu, 23 Jun 2011 15:13:36 -0700
MIME-Version: 1.0 (Apple Message framework v1242)
Content-Type: text/plain; charset="us-ascii"
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 23 Jun 2011 18:13:31 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <1A7FA259-3266-4FA6-91B7-2180A1065710@nominum.com>
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>   <63524B72-6890-48E4-926F-030744B415A2@nominum.com>    <8F573F95-319F-4DC2-8D07-59C431E0E65E@nominum.com> 
To: Philip Homburg 
X-Mailer: Apple Mail (2.1242)
Cc: "v6ops@ietf.org" , "ipv6@ietf.org" 
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 22:14:14 -0000

On Jun 23, 2011, at 6:08 PM, Philip Homburg wrote:
> Ideally, clients use end-to-end crypto to keep themselves secure, but =
the
> network still has to be protected against denial of service attacks.

No, strictly speaking the *clients* need to be protected against DoS =
attacks.   One way to do this is to strongly control multicast on the =
network.   But the network itself cannot suffer from rogue RA =
advertisements: it is other clients on the network that suffer.   I =
realize that this seems like a trivial distinction, but I think it's =
important to be clear about it, because it's not always a safe =
assumption that any given network will be protected, and hence if we =
really care about DoS attacks as a general problem, we need to address =
the problem in a way that will work not just on hub-and-spoke networks, =
but on broadcast networks as well.


From marka@isc.org  Thu Jun 23 16:41:39 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2346D11E80D8; Thu, 23 Jun 2011 16:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level: 
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQnHEprWOFGB; Thu, 23 Jun 2011 16:41:38 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 689D711E808B; Thu, 23 Jun 2011 16:41:38 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 8FB605F98E6; Thu, 23 Jun 2011 23:41:20 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6D519216C7B; Thu, 23 Jun 2011 23:41:18 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 88100112A691; Fri, 24 Jun 2011 09:41:14 +1000 (EST)
To: "v6ops@ietf.org" , "ipv6@ietf.org" 
From: Mark Andrews 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>   <63524B72-6890-48E4-926F-030744B415A2@nominum.com>    <8F573F95-319F-4DC2-8D07-59C431E0E65E@nominum.com>  <1A7FA259-3266-4FA6-91B7-2180A1065710@nominum.com>
In-reply-to: Your message of "Thu, 23 Jun 2011 18:13:31 -0400." <1A7FA259-3266-4FA6-91B7-2180A1065710@nominum.com>
Date: Fri, 24 Jun 2011 09:41:14 +1000
Message-Id: <20110623234114.88100112A691@drugs.dv.isc.org>
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 23:41:39 -0000

For many years I just filtered out rogue RA's on my laptop at IETF.

I looked at which routers were advertising which prefixes and
configured a allow list in the firewall for those that looked correct
and denied the rest.  Then I removed the bogus addresses, generated
as the result of those RA's, from the interface.  I also remove the
default route when it pointed to a bogus router and performed a
router solicitation.  Making that into a GUI so the user can point
and click should be relatively easy.

Add to that next hop selection where you only send to a router that
is advertising a prefix covering the source address you are using
and trying from multiple source address, you can mostly eliminate
the impact of accidental rogue RA's without needing to filter.

If you want to eliminate malicious RA's then you need the network
operator to help by using CGA's or similar so you can identify
spoofed from non-spoofed RA's.  The node can learn which router is
using CGA's and automatically filter spoofed ones.  By keeping a
little more state it can also automatically cleanup the side effects
from those spoofed RA's.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From ipng@69706e6720323030352d30312d31340a.nosense.org  Thu Jun 23 17:44:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDE711E8081; Thu, 23 Jun 2011 17:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.995
X-Spam-Level: 
X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awNEJ8XvzobR; Thu, 23 Jun 2011 17:44:16 -0700 (PDT)
Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id C12A511E819D; Thu, 23 Jun 2011 17:44:15 -0700 (PDT)
Received: from 219-90-231-100.ip.adam.com.au ([219.90.231.100] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QZuVE-0007Xm-Mq; Fri, 24 Jun 2011 10:14:08 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 089C13B33E; Fri, 24 Jun 2011 10:14:08 +0930 (CST)
Date: Fri, 24 Jun 2011 10:14:06 +0930
From: Mark Smith 
To: Ted Lemon 
Message-ID: <20110624101406.6498e2b0@opy.nosense.org>
In-Reply-To: <63524B72-6890-48E4-926F-030744B415A2@nominum.com>
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>   <63524B72-6890-48E4-926F-030744B415A2@nominum.com>
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 00:44:17 -0000

Hi,

On Thu, 23 Jun 2011 16:30:37 -0400
Ted Lemon  wrote:

> On Jun 23, 2011, at 2:36 AM, Mikael Abrahamsson wrote:
> > I don't see how it can be fixed. Short of encrypting all traffic and pre-distributing keys, ethernet can't be fixed without the "bandaids" you seem to call the measures being used widely to assure ethernet can in fact be used securely.
> 
> There probably is no single solution.   But let's consider the solution Mark proposed:

Just to be clear, I wasn't suggesting the methods commonly used in ETTH
networks is a universal solution.

It seems to me that organisations that would care the most about
malicious RAs are SPs. Yet they're already likely to have or put
measures in place that naturally mitigate that risk as well as
achieving other goals that they have such as traffic billing. So
malicious RAs may not be as as much of a threat to them as
people might think. Implementing these sorts of measures are just a
natural cost of business, because it is part of ensuring your service is
available, and ensuring one customer has limited ability to disrupt
another's service.

Enterprise networks may be most concerned about accidental RAs, as they
typically tend to have more control over what hosts can do because they
operate them, rather than the customers in the SP case. As Ray
mentioned, if the cost of implementing RA guard is prohibitive, some
enterprises might just accept the risk and consequences of an
occasional accidental RA.

Are there other contexts that I haven't identified? The reason I've
thought about these contexts is that proposals such as
universally preventing fragmentation in ND is a one-size-fits-all
approach to the problem that probably can't be reversed if chosen.

> use the fact that you control the infrastructure to control the flow
> of packets on the network in such a way that rogue RAs cannot reach
> leaf nodes.   The reason I object to this solution, in addition to the
> fact that it breaks multicast, is that it's a firewall solution: the
> client doesn't know it's safe, and as soon as it connects to a network
> that's not protected in this way, it's vulnerable.   But the model of
> using infrastructure control as a credential is interesting.
> 
> Is there a way that someone who is not running 802.1x can demonstrate that they control layer 2?   It seems to me that for most examples of Layer 2 that we care about, the answer is probably yes.   So then if the secure link to the router can be used to communicate a secret, and the network can provide that secret back to the user in a way that a rogue RA agent could not do, then the end node can discriminate between rogue RAs and legitimate RAs.
> 
> E.g., suppose we have a WiFi network secured with WPA.   WPA uses an X.509 cert to establish the identity of the WPA server.   If the private key authenticated by the cert is used to sign the secret the client provides, then the client can be sure that the router it is talking to is controlled by the same entity that controls WPA.   Since WPA is tied directly to the infrastructure, that's proof that the router is managed by the infrastructure provider.
>  

This is basically Secure Neighbor Discovery (SeND) with the addition of
key distribution via the 802.1x. I'm not sure the combination exists or
is possible, I've been meaning to look into it for a while.

> Another solution that would work well in the case of frequently-visited networks would be the model that ssh uses: keep a list of good routers.   When you connect to a wire, prefer routers on the "good" list to new routers.   If no RAs come from routers on the "good" list, then you need a heuristic to decide whether or not a new router is good.   The mechanism I described in the previous paragraph could be used to handle some exceptional cases; other heuristics could be used to handle cases where the link is not secured in any way: if I try to establish secure connections, and those connections turn out to be exposed to MITM attacks, then the router (and hence, the RA from that router) are not trustworthy.
> 
> The problem with this stuff is not that it's impossible.   It's that it's not simple.   If you want your communications to be secure, you have to secure them.   If all your communications are secure, then a rogue RA can only do two things: deny service, or allow an attacker to do traffic analysis and/or cryptanalysis that would not otherwise be possible.
> 

Agree with it not being simple. A secure protocol to authenticate RAs
already exists - SeND. The problem with it is the lack of
implementations and the key distribution problem. Since we know that
methods such as RA guard aren't really "properly secure" and can't be,
I think it is important to not to have unrealistic security
expectations of them.

Regards,
Mark.

From farmer@umn.edu  Thu Jun 23 18:30:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCBE11E8084; Thu, 23 Jun 2011 18:30:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wob4i98digjP; Thu, 23 Jun 2011 18:30:16 -0700 (PDT)
Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8F411E807C; Thu, 23 Jun 2011 18:30:16 -0700 (PDT)
Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP Thu, 23 Jun 2011 20:30:08 -0500 (CDT)
X-Umn-Remote-Mta: [N] mail-iy0-f171.google.com [209.85.210.171] #+LO+TR
X-Umn-Classification: local
Received: by mail-iy0-f171.google.com with SMTP id 12so3134063iyi.16 for ; Thu, 23 Jun 2011 18:30:08 -0700 (PDT)
Received: by 10.43.132.196 with SMTP id hv4mr624887icc.105.1308879007836; Thu, 23 Jun 2011 18:30:07 -0700 (PDT)
Received: from x-128-101-232-243.uofm-secure.wireless.umn.edu (x-128-101-232-243.uofm-secure.wireless.umn.edu [128.101.232.243]) by mx.google.com with ESMTPS id f19sm1187427ibl.49.2011.06.23.18.30.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Jun 2011 18:30:07 -0700 (PDT)
Message-ID: <4E03E89D.3010603@umn.edu>
Date: Thu, 23 Jun 2011 20:30:05 -0500
From: David Farmer 
Organization: University of Minnesota
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Ted Lemon 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>		<20110622210451.60ad8bce@opy.nosense.org>			<20110623095548.24d89d7f@opy.nosense.org>		 <63524B72-6890-48E4-926F-030744B415A2@nominum.com>
In-Reply-To: <63524B72-6890-48E4-926F-030744B415A2@nominum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: David Farmer 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 01:30:17 -0000

On 6/23/11 15:30 CDT, Ted Lemon wrote:
> On Jun 23, 2011, at 2:36 AM, Mikael Abrahamsson wrote:
>> I don't see how it can be fixed. Short of encrypting all traffic
>> and pre-distributing keys, ethernet can't be fixed without the
>> "bandaids" you seem to call the measures being used widely to
>> assure ethernet can in fact be used securely.
>
> There probably is no single solution.   But let's consider the
> solution Mark proposed: use the fact that you control the
> infrastructure to control the flow of packets on the network in such
> a way that rogue RAs cannot reach leaf nodes.   The reason I object
> to this solution, in addition to the fact that it breaks multicast,
> is that it's a firewall solution: the client doesn't know it's safe,
> and as soon as it connects to a network that's not protected in this
> way, it's vulnerable.   But the model of using infrastructure control
> as a credential is interesting.

I don't think of RA-Guard and DHCP-Guard filters as security measures, 
they are simply network management and operations techniques.  They 
don't make the network more secure, but they can make operating some 
networks much easier.  They probably also can make some networks more 
reliable and usable too.  But, calling them more secure is probably a 
stretch.

A quick story; 6 years ago we replaced our network and implemented IPv4 
DHCP-Guard filters on all access ports on our network, doing this 
eliminated about 300 trouble tickets a year from rogue IPv4 DHCP servers 
showing up on our network, home routers used as cheep switches without 
disabling DHCP, Internet connection sharing software on laptops, etc... 
  Between staff time to track down the offending devices and lost 
productivity of the effected users, lets use a conservative average cost 
of $500 an incident, that is $150K a year of cost savings to the 
University.  This didn't make our network one bit more secure, it is 
still a wide open network that anyone can use, but it is now cheaper to 
run and provides a more reliable and usable service to our users.

This draft is need, if nothing else to let people know about this issue, 
and if we can find an acceptable way to mitigate the issue great, but 
classic RA-Guard is still a very effective network management and 
operations technique, with or without mitigation of this issue. 
Unintentional rogue RAs are big issues in a LAN environment of any 
substantial size.  However, without mitigation of this issue, RA-Guard 
is not an effective network security technique. It can't deal with 
malicious rouge RAs that are a security threat.

> Is there a way that someone who is not running 802.1x can demonstrate
> that they control layer 2?   It seems to me that for most examples of
> Layer 2 that we care about, the answer is probably yes.   So then if
> the secure link to the router can be used to communicate a secret,
> and the network can provide that secret back to the user in a way
> that a rogue RA agent could not do, then the end node can
> discriminate between rogue RAs and legitimate RAs.
>
> E.g., suppose we have a WiFi network secured with WPA.   WPA uses an
> X.509 cert to establish the identity of the WPA server.   If the
> private key authenticated by the cert is used to sign the secret the
> client provides, then the client can be sure that the router it is
> talking to is controlled by the same entity that controls WPA.
> Since WPA is tied directly to the infrastructure, that's proof that
> the router is managed by the infrastructure provider.

OH... That's an intriguing idea, use 802.1x to securely feed SEND.  That 
might even make using SEND practical in an open network environment like 
a University.  Its a massing protocol layering violation, but most 
things in the security realm are.

> Another solution that would work well in the case of
> frequently-visited networks would be the model that ssh uses: keep a
> list of good routers.   When you connect to a wire, prefer routers on
> the "good" list to new routers.   If no RAs come from routers on the
> "good" list, then you need a heuristic to decide whether or not a new
> router is good.   The mechanism I described in the previous paragraph
> could be used to handle some exceptional cases; other heuristics
> could be used to handle cases where the link is not secured in any
> way: if I try to establish secure connections, and those connections
> turn out to be exposed to MITM attacks, then the router (and hence,
> the RA from that router) are not trustworthy.
>
> The problem with this stuff is not that it's impossible.   It's that
> it's not simple.   If you want your communications to be secure, you
> have to secure them.   If all your communications are secure, then a
> rogue RA can only do two things: deny service, or allow an attacker
> to do traffic analysis and/or cryptanalysis that would not otherwise
> be possible.

Yep, if you secure your communications then these issues are only 
network management and operational issues, not security issues. However, 
depending on the network, you still might want to use RA-Guard to 
prevent such operational issues.

-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

From fernando.gont.netbook.win@gmail.com  Thu Jun 23 20:33:37 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA85611E8097; Thu, 23 Jun 2011 20:33:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level: 
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[AWL=0.411,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxdAdRGq4mu7; Thu, 23 Jun 2011 20:33:36 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id B31AD11E81B3; Thu, 23 Jun 2011 20:33:36 -0700 (PDT)
Received: by yie30 with SMTP id 30so1437833yie.31 for ; Thu, 23 Jun 2011 20:33:34 -0700 (PDT)
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:content-type:content-transfer-encoding; bh=VHkviNnV1glA6gGv1QWI3+RkrhB9qz3ZwCPrnL0jNac=; b=fATGzcm9noDyhf9BNoepsQQWE32+NpBYn1zMiOrJ2qggpflsaaMSLaPMA6RV4GWFnS hYmKg8iJdfE48S/D9YzQlBfySvI++Up7nGCpaHaVS/HswC4O43Sg5UOY1KErcLIyT6P3 4A59lD8kZhHt0/AYlh4IeQAP39eyRvx3xIyL8=
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:content-type :content-transfer-encoding; b=iA2+Y1o1UiveWszBGI+KbvYEg+T/1qi09d6HSf0xLa+/25L3QhlUjB4k+kDA3YQNAN wDbbe/k6EkvrmPebxSNR9jOH7DAqY1zUq550CtBA4TUHhtH9/00VcCxvWE5dRo5kI8za naDgD1UiQqmK3ogGA5C+yI+oNsAXTJLBmS0nA=
Received: by 10.101.189.38 with SMTP id r38mr2917210anp.119.1308886414622; Thu, 23 Jun 2011 20:33:34 -0700 (PDT)
Received: from [192.168.123.103] ([190.48.244.84]) by mx.google.com with ESMTPS id w13sm2139410ano.23.2011.06.23.20.33.31 (version=SSLv3 cipher=OTHER); Thu, 23 Jun 2011 20:33:33 -0700 (PDT)
Sender: Fernando Gont 
Message-ID: <4E0401AD.8070108@gont.com.ar>
Date: Fri, 24 Jun 2011 00:17:01 -0300
From: Fernando Gont 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
MIME-Version: 1.0
To: Mark Smith 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>	 <20110622210451.60ad8bce@opy.nosense.org>
In-Reply-To: <20110622210451.60ad8bce@opy.nosense.org>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: RJ Atkinson , v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 03:33:37 -0000

On 06/22/2011 08:34 AM, Mark Smith wrote:

>> I think it is a bit ironic that if a L2 device has to parse all extension
>> headers, that then L2 switching of IPv6 packets will be more expensive that
>> L3 routing them.
> 
> It may be getting to the point where it'd probably be easier
> to address these issues by taking away hosts' ability to multicast to
> other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke
> mode of LAN operation, allowing the designated routers to also act as
> traffic sanitisers for on-link inter-host traffic.

Two comments:

* Hosts would still need to multicast RSs
* This does nto prevent attackers from sending ND packets *unicast* to
their victims.

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  Thu Jun 23 21:30:10 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3733811E8197; Thu, 23 Jun 2011 21:30:10 -0700 (PDT)
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.100,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnUo0D4gj7yc; Thu, 23 Jun 2011 21:30:09 -0700 (PDT)
Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by ietfa.amsl.com (Postfix) with ESMTP id EDB1011E80AF; Thu, 23 Jun 2011 21:30:08 -0700 (PDT)
Received: from 114-30-114-141.ip.adam.com.au ([114.30.114.141] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QZy1m-0003Gr-Kr; Fri, 24 Jun 2011 13:59:58 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 048653B33E; Fri, 24 Jun 2011 13:59:58 +0930 (CST)
Date: Fri, 24 Jun 2011 13:59:57 +0930
From: Mark Smith 
To: Fernando Gont 
Message-ID: <20110624135957.0664aa5e@opy.nosense.org>
In-Reply-To: <4E0401AD.8070108@gont.com.ar>
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org> <4E0401AD.8070108@gont.com.ar>
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 04:30:10 -0000

Hi Fernando,


On Fri, 24 Jun 2011 00:17:01 -0300
Fernando Gont  wrote:

> On 06/22/2011 08:34 AM, Mark Smith wrote:
> 
> >> I think it is a bit ironic that if a L2 device has to parse all extension
> >> headers, that then L2 switching of IPv6 packets will be more expensive that
> >> L3 routing them.
> > 
> > It may be getting to the point where it'd probably be easier
> > to address these issues by taking away hosts' ability to multicast to
> > other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke
> > mode of LAN operation, allowing the designated routers to also act as
> > traffic sanitisers for on-link inter-host traffic.
> 
> Two comments:
> 
> * Hosts would still need to multicast RSs

Yes, but the layer 2 device only delivers those multicast RSes to ports
that it has been told are attached to authorised routers.

> * This does nto prevent attackers from sending ND packets *unicast* to
> their victims.
> 

Actually it can.  Have a look at the following -

http://tools.ietf.org/html/draft-ietf-6man-dad-proxy-01

The layer 3 hub-and-spoke forwarding topology described can also be and
is likely to also be enforced at layer 2, by preventing layer 2
forwarding of traffic between designated host ports, limiting it to
host port to router port, or router port to host port.

It's interesting to look back on where we've come from. On simple
10BASE2 and earlier Ethernet, broadcast/multicast was cheap, because it
was the inherent nature of it's bus topology. After we moved to
bridges/switches with individual devices attached to each port, this
broadcast/multicast capability had to be actively emulated, because a
star topology does not have a natural broadcast/multicast capability.
Implementing hub-and-spoke forwarding paths in a bridge/switch is
not much more than reducing the requirement to emulate something that
fundamentally wasn't natural in the first place.

Regards,
Mark.

From swmike@swm.pp.se  Thu Jun 23 22:14:58 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B6021F848A; Thu, 23 Jun 2011 22:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.566
X-Spam-Level: 
X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QGUygd3LJQO; Thu, 23 Jun 2011 22:14:58 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id F293321F8488; Thu, 23 Jun 2011 22:14:57 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id E336B9C; Fri, 24 Jun 2011 07:14:52 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DEF3E9A; Fri, 24 Jun 2011 07:14:52 +0200 (CEST)
Date: Fri, 24 Jun 2011 07:14:52 +0200 (CEST)
From: Mikael Abrahamsson 
To: Ted Lemon 
In-Reply-To: <63524B72-6890-48E4-926F-030744B415A2@nominum.com>
Message-ID: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>   <63524B72-6890-48E4-926F-030744B415A2@nominum.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 05:14:59 -0000

On Thu, 23 Jun 2011, Ted Lemon wrote:

> Is there a way that someone who is not running 802.1x can demonstrate 
> that they control layer 2?

Doesn't 802.1x only control access as a non/off switch? As soon as you're 
connected to the network, I thought it was back to flat L2 default 
ethernet again?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From swmike@swm.pp.se  Thu Jun 23 22:16:13 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9316511E8071; Thu, 23 Jun 2011 22:16:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level: 
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3psnODBxCU4; Thu, 23 Jun 2011 22:16:13 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE2A11E80AF; Thu, 23 Jun 2011 22:16:08 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6423F9C; Fri, 24 Jun 2011 07:16:07 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 621C49A; Fri, 24 Jun 2011 07:16:07 +0200 (CEST)
Date: Fri, 24 Jun 2011 07:16:07 +0200 (CEST)
From: Mikael Abrahamsson 
To: "Manfredi, Albert E" 
In-Reply-To: 
Message-ID: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>   <63524B72-6890-48E4-926F-030744B415A2@nominum.com>   
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "v6ops@ietf.org" , "ipv6@ietf.org" 
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 05:16:14 -0000

On Thu, 23 Jun 2011, Manfredi, Albert E wrote:

> It is service providers that are interested in protecting their 
> networks, in this discussion. If they also happen to protect their 
> clients, that is just a nice byproduct.

We want to protect the Internet from our customers, not our customers from 
the Internet.

> Service providers want to keep malicious clients from degrading their 
> network.

Exactly.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From ipng@69706e6720323030352d30312d31340a.nosense.org  Thu Jun 23 23:05:21 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D37B9E800A; Thu, 23 Jun 2011 23:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.82
X-Spam-Level: 
X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yovAELry9+KR; Thu, 23 Jun 2011 23:05:21 -0700 (PDT)
Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by ietfa.amsl.com (Postfix) with ESMTP id 111E6228006; Thu, 23 Jun 2011 23:05:20 -0700 (PDT)
Received: from 114-30-114-141.ip.adam.com.au ([114.30.114.141] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QZzVz-0007x2-W1; Fri, 24 Jun 2011 15:35:16 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 6C8C33B33E; Fri, 24 Jun 2011 15:35:15 +0930 (CST)
Date: Fri, 24 Jun 2011 15:35:15 +0930
From: Mark Smith 
To: Mikael Abrahamsson 
Message-ID: <20110624153515.4e516f1c@opy.nosense.org>
In-Reply-To: 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>   <63524B72-6890-48E4-926F-030744B415A2@nominum.com> 
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 06:05:21 -0000

On Fri, 24 Jun 2011 07:14:52 +0200 (CEST)
Mikael Abrahamsson  wrote:

> On Thu, 23 Jun 2011, Ted Lemon wrote:
> 
> > Is there a way that someone who is not running 802.1x can demonstrate 
> > that they control layer 2?
> 
> Doesn't 802.1x only control access as a non/off switch? As soon as you're 
> connected to the network, I thought it was back to flat L2 default 
> ethernet again?
> 

The thing I've been intending to investigate was whether 802.1x could
deliver non-authentication related attributes to the supplicant upon
successful authentication, similar to RADIUS Access-Accept messages. If
it could, I think that could be used to perform the key distribution to
bootstrap SeND.

Regards,
Mark.

From pch-b2B3A6689@u-1.phicoh.com  Fri Jun 24 02:06:58 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD42611E809B; Fri, 24 Jun 2011 02:06:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.544
X-Spam-Level: 
X-Spam-Status: No, score=-8.544 tagged_above=-999 required=5 tests=[AWL=0.055,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rg6ONwQ6GWZg; Fri, 24 Jun 2011 02:06:58 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF93228005; Fri, 24 Jun 2011 02:06:56 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1Qa2Lm-0001hFC; Fri, 24 Jun 2011 11:06:54 +0200
Message-Id: 
To: Ted Lemon 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>   <63524B72-6890-48E4-926F-030744B415A2@nominum.com>    <8F573F95-319F-4DC2-8D07-59C431E0E65E@nominum.com>  <1A7FA259-3266-4FA6-91B7-2180A1065710@nominum.com> 
In-reply-to: Your message of "Thu, 23 Jun 2011 18:13:31 -0400 ." <1A7FA259-3266-4FA6-91B7-2180A1065710@nominum.com> 
Date: Fri, 24 Jun 2011 11:06:46 +0200
Cc: "v6ops@ietf.org" , "ipv6@ietf.org" 
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 09:06:58 -0000

In your letter dated Thu, 23 Jun 2011 18:13:31 -0400 you wrote:
>On Jun 23, 2011, at 6:08 PM, Philip Homburg wrote:
>> Ideally, clients use end-to-end crypto to keep themselves secure, but =
>the
>> network still has to be protected against denial of service attacks.
>
>No, strictly speaking the *clients* need to be protected against DoS =
>attacks.   One way to do this is to strongly control multicast on the =
>network.   But the network itself cannot suffer from rogue RA =
>advertisements: it is other clients on the network that suffer.   

You are right if we just limit ourselves to RAs. But my comment was meant to
be broader than that. 

If a malcious client configures a router's MAC address on his ethernet card
then it is not the clients' faults if L2 switches route traffic to the wrong
port. Same thing if a malicious client uses another client's IP address and
the router gets confused.



From pch-b2B3A6689@u-1.phicoh.com  Fri Jun 24 02:12:13 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9496411E809B; Fri, 24 Jun 2011 02:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.549
X-Spam-Level: 
X-Spam-Status: No, score=-8.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dci1-OfjDe1c; Fri, 24 Jun 2011 02:12:13 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9204D11E8093; Fri, 24 Jun 2011 02:12:12 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1Qa2Qt-0001iEC; Fri, 24 Jun 2011 11:12:11 +0200
Message-Id: 
To: David Farmer 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>   <63524B72-6890-48E4-926F-030744B415A2@nominum.com> <4E03E89D.3010603@umn.edu> 
In-reply-to: Your message of "Thu, 23 Jun 2011 20:30:05 -0500 ." <4E03E89D.3010603@umn.edu> 
Date: Fri, 24 Jun 2011 11:12:10 +0200
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 09:12:13 -0000

In your letter dated Thu, 23 Jun 2011 20:30:05 -0500 you wrote:
>OH... That's an intriguing idea, use 802.1x to securely feed SEND.  That 
>might even make using SEND practical in an open network environment like 
>a University.  Its a massing protocol layering violation, but most 
>things in the security realm are.

I'm not sure how that's supposed to improve things. To make 802.1x secure
(for the client) the client needs to have the server's certificate. Otherwise
there can be a man-in-the-middle attack.

If you have a way of providing clients with certificates, why not distribute
the keys for SEND directly?

From internet-drafts@ietf.org  Fri Jun 24 05:24:20 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552EF11E809B; Fri, 24 Jun 2011 05:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level: 
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qz8R7j2GNxHB; Fri, 24 Jun 2011 05:24:19 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F1B11E8092; Fri, 24 Jun 2011 05:24:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.55
Message-ID: <20110624122419.14390.80232.idtracker@ietfa.amsl.com>
Date: Fri, 24 Jun 2011 05:24:19 -0700
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 12:24:20 -0000

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

	Title           : Request to move Connection of IPv6 Domains via IPv4 Clou=
ds (6to4) to Historic status
	Author(s)       : Ole Troan
	Filename        : draft-ietf-v6ops-6to4-to-historic-05.txt
	Pages           : 7
	Date            : 2011-06-24

   Experience with the "Connection of IPv6 Domains via IPv4 Clouds
   (6to4)" IPv6 transitioning mechanism has shown that the mechanism is
   unsuitable for widespread deployment and use in the Internet.  This
   document requests that RFC3056 and the companion document "An Anyca=
st
   Prefix for 6to4 Relay Routers" RFC3068 are made obsolete and moved =
to
   historic status.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-to-historic-05.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-to-historic-05.txt

From ichiroumakino@gmail.com  Fri Jun 24 05:27:24 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263B021F848A for ; Fri, 24 Jun 2011 05:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml+1qwM2ee1k for ; Fri, 24 Jun 2011 05:27:23 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 726FE21F8487 for ; Fri, 24 Jun 2011 05:27:23 -0700 (PDT)
Received: by pvh18 with SMTP id 18so1822704pvh.31 for ; Fri, 24 Jun 2011 05:27:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=Hj8GfJCr67M3Fbd1dJg3VDufL9Hm3s0F45NNmg1wYrQ=; b=ccapE8KUIIe2elgf1g2JZStbIJ72j3qUKQo26jW6x1+ya5+POZVZkdYOxTh/PHSPrt AgKe+6CYUT6w+gaplnXtmy2vtlHLPvjk+kAmgK4tHgG6s6BjqtFY5Y7lDhRexWzoo6yB IzSlEH5kNrjB0J3aM2W5IVLV29zoOxWkA+ngk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=WnESO/j0gO9Np6REvtv6zGDcHfWl/brESqebTeM7sTm4Rl1tjtT0hsgCgf9AqTQYPi qUmFj3oX4KJtmd+IUnxrd4hjdmaDov2NlsJXwIvUQ5mTT2m+4wf9o8nfNg/fxUbYvwaE ggyV3UlT/H5E9IH/pNwSetYWTN/fwIgY49P5E=
Received: by 10.68.4.194 with SMTP id m2mr1617985pbm.228.1308918443116; Fri, 24 Jun 2011 05:27:23 -0700 (PDT)
Received: from [10.21.79.25] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id d1sm2031724pbj.24.2011.06.24.05.27.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Jun 2011 05:27:21 -0700 (PDT)
Sender: Ole Troan 
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: Ole Troan 
In-Reply-To: <20110624122419.14390.80232.idtracker@ietfa.amsl.com>
Date: Fri, 24 Jun 2011 14:27:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7270A7B5-A9FB-407A-95E5-D11A456F59E5@employees.org>
References: <20110624122419.14390.80232.idtracker@ietfa.amsl.com>
To: IPv6 Operations Working Group 
X-Mailer: Apple Mail (2.1084)
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 12:27:24 -0000

updated with Gen-Art comments and feedback from IANA:
=
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-6to4-to-historic-05.=
txt

cheers,
Ole


On Jun 24, 2011, at 14:24 , 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
> 	Title           : Request to move Connection of IPv6 Domains via =
IPv4 Clouds (6to4) to Historic status
> 	Author(s)       : Ole Troan
> 	Filename        : draft-ietf-v6ops-6to4-to-historic-05.txt
> 	Pages           : 7
> 	Date            : 2011-06-24
>=20
>   Experience with the "Connection of IPv6 Domains via IPv4 Clouds
>   (6to4)" IPv6 transitioning mechanism has shown that the =
mechanism is
>   unsuitable for widespread deployment and use in the Internet.  This
>   document requests that RFC3056 and the companion document "An =
Anycast
>   Prefix for 6to4 Relay Routers" RFC3068 are made obsolete and =
moved to
>   historic status.
>=20
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-to-historic-05.t=
xt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> =
ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-to-historic-05.tx=
t
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From fernando.gont.netbook.win@gmail.com  Fri Jun 24 05:59:03 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FB521F84DB; Fri, 24 Jun 2011 05:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.247
X-Spam-Level: 
X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[AWL=0.352,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5NXezMLfg1t; Fri, 24 Jun 2011 05:59:03 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03B7C21F84DA; Fri, 24 Jun 2011 05:59:02 -0700 (PDT)
Received: by yie30 with SMTP id 30so1642711yie.31 for ; Fri, 24 Jun 2011 05:59:02 -0700 (PDT)
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:content-type:content-transfer-encoding; bh=YaU7XhZAd9BAWvwtzb9e8KoGmilp4AtKDmb/VML+54Y=; b=pkPIANfSHUXqjCsOZ6Nll1yW3fOIafoRiaLZneDI3+rULJlFkqkRIQwVUQ1RntmHTP hWqAsT3t1k25KPH7S3Takn1WkkJMASMa/SUYcD9y+Wm8VO88lYduB1S3l0CMr+LZ+6J7 cJutrmXgYopFEUR/HTHII1kehMuNC+7mhiDr4=
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:content-type :content-transfer-encoding; b=kd9aNl/rViLpgAW8S3XaJYlLMM+0/Wt6Y9Aed/6Wkt8AcPnfdXd+xgqfH1rnuYhYwj sWi+ZqchsdorPANXeha8iEkfWk1i/X6sLim0dVG6j28czEFKxGMj+oV7zNX+HgORSh+j hdsi2glZu4XI+w3n3yM78EdfhqRE3/0AV5OX4=
Received: by 10.101.165.10 with SMTP id s10mr749089ano.10.1308920341874; Fri, 24 Jun 2011 05:59:01 -0700 (PDT)
Received: from [192.168.123.103] ([190.48.229.153]) by mx.google.com with ESMTPS id i6sm2529090anm.25.2011.06.24.05.58.58 (version=SSLv3 cipher=OTHER); Fri, 24 Jun 2011 05:59:00 -0700 (PDT)
Sender: Fernando Gont 
Message-ID: <4E047E2A.806@gont.com.ar>
Date: Fri, 24 Jun 2011 09:08:10 -0300
From: Fernando Gont 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
MIME-Version: 1.0
To: David Farmer 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>		<20110622210451.60ad8bce@opy.nosense.org>			<20110623095548.24d89d7f@opy.nosense.org>			<63524B72-6890-48E4-926F-030744B415A2@nominum.com> <4E03E89D.3010603@umn.edu>
In-Reply-To: <4E03E89D.3010603@umn.edu>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 12:59:03 -0000

On 06/23/2011 10:30 PM, David Farmer wrote:
>> There probably is no single solution.   But let's consider the
>> solution Mark proposed: use the fact that you control the
>> infrastructure to control the flow of packets on the network in such
>> a way that rogue RAs cannot reach leaf nodes.   The reason I object
>> to this solution, in addition to the fact that it breaks multicast,
>> is that it's a firewall solution: the client doesn't know it's safe,
>> and as soon as it connects to a network that's not protected in this
>> way, it's vulnerable.   But the model of using infrastructure control
>> as a credential is interesting.
> 
> I don't think of RA-Guard and DHCP-Guard filters as security measures,
> they are simply network management and operations techniques.  They
> don't make the network more secure, but they can make operating some
> networks much easier.  

If they can mitigate specific attack vectors, they do make the network
more secure.

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 farmer@umn.edu  Fri Jun 24 06:39:18 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7580D11E8081; Fri, 24 Jun 2011 06:39:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level: 
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nRMAFFrh+xF; Fri, 24 Jun 2011 06:39:17 -0700 (PDT)
Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7953011E8076; Fri, 24 Jun 2011 06:39:17 -0700 (PDT)
Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.214.171]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP Fri, 24 Jun 2011 08:39:07 -0500 (CDT)
X-Umn-Remote-Mta: [N] mail-iw0-f171.google.com [209.85.214.171] #+LO+TR
X-Umn-Classification: local
Received: by iwn34 with SMTP id 34so3734055iwn.16 for ; Fri, 24 Jun 2011 06:39:06 -0700 (PDT)
Received: by 10.43.61.196 with SMTP id wx4mr3020640icb.310.1308922745976; Fri, 24 Jun 2011 06:39:05 -0700 (PDT)
Received: from vpn0-823.vpn.umn.edu (vpn0-823.vpn.umn.edu [134.84.3.55]) by mx.google.com with ESMTPS id vn4sm2617099icb.7.2011.06.24.06.39.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Jun 2011 06:39:04 -0700 (PDT)
Message-ID: <4E049375.5070603@umn.edu>
Date: Fri, 24 Jun 2011 08:39:01 -0500
From: David Farmer 
Organization: University of Minnesota
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Philip Homburg 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org>   <20110623095548.24d89d7f@opy.nosense.org>   <63524B72-6890-48E4-926F-030744B415A2@nominum.com> <4E03E89D.3010603@umn.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: David Farmer 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 13:39:18 -0000

On 6/24/11 04:12 CDT, Philip Homburg wrote:
> In your letter dated Thu, 23 Jun 2011 20:30:05 -0500 you wrote:
>> OH... That's an intriguing idea, use 802.1x to securely feed SEND.  That
>> might even make using SEND practical in an open network environment like
>> a University.  Its a massing protocol layering violation, but most
>> things in the security realm are.
>
> I'm not sure how that's supposed to improve things. To make 802.1x secure
> (for the client) the client needs to have the server's certificate. Otherwise
> there can be a man-in-the-middle attack.
>
> If you have a way of providing clients with certificates, why not distribute
> the keys for SEND directly?

 From a technical and theoretical point of view you are correct, they 
are fundamentally the same problem. However, from a practical point of 
view, there are available solutions and tools, even some commercially 
available, for dealing with securely configuring 802.1x, especially in 
the wireless realm with WPA2, at many different scales, from the home 
user network all the way up to multinational enterprise.

The issue even has some mind share with the non-technical end users 
world, thanks to the virus like spread of wireless home gateways.

So, the key/certificate distribution problem is hard enough to do right 
once.  We are getting close with 802.1x and WPA2, why not build on that 
for SEND?  I'm not saying you shouldn't be able to configure SEND 
separately if you wish, and if you can that might be even more secure. 
But, being able to securely generate keys or obtain certificates for 
SEND using 802.1x and/or WPA2 would create a much lower barrier to entry 
for SEND.

But even with all that, we don't eliminate the usefulness of RA-Guard in 
may situations.

-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

From fernando.gont.netbook.win@gmail.com  Fri Jun 24 07:59:33 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA4F21F8445; Fri, 24 Jun 2011 07:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.458
X-Spam-Level: 
X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.141,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0U1VxbjfKYuW; Fri, 24 Jun 2011 07:59:28 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92A7D21F8440; Fri, 24 Jun 2011 07:59:28 -0700 (PDT)
Received: by gwb20 with SMTP id 20so1696179gwb.31 for ; Fri, 24 Jun 2011 07:59:28 -0700 (PDT)
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:content-type:content-transfer-encoding; bh=Xvfypji8FPO1O3AzTgH1Zk9J7/UyhRQembFnnwiXM4A=; b=I7bmC8ujjGbpbujcWyvnVWkDJnG81sZvr+MXY5d3MGcLywU91RZYYB+AsWjIUARANq mi+ewOdqf2pBFot/lcU7vk8GunNMtVYDgrnTaSTFj0B8YZCv5YwKaIR4hCZ5omW90qiQ 2pjVq4hag2nRRPpaiNVxM407eUgGssgFUK2eQ=
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:content-type :content-transfer-encoding; b=wASJAl8ESkt73qwlHv3NPp7XZyD1a8q6H4AbW0d3aTIUXyPdcRAlfykwvvQBOwUEJ7 nCG+bkXGrO0qJ20fkUZS0VTy2EmjDFwSskjJO4vra2A7wm59Fr1g7GkN2nmq2kwBqcLu 2p8EVDi8SrISpBSQQ69LFg62kBytPVg+W3P4A=
Received: by 10.90.248.10 with SMTP id v10mr3937217agh.54.1308927566308; Fri, 24 Jun 2011 07:59:26 -0700 (PDT)
Received: from [192.168.123.103] ([190.48.229.153]) by mx.google.com with ESMTPS id w19sm2619196anf.12.2011.06.24.07.59.22 (version=SSLv3 cipher=OTHER); Fri, 24 Jun 2011 07:59:24 -0700 (PDT)
Sender: Fernando Gont 
Message-ID: <4E048FC7.5070706@gont.com.ar>
Date: Fri, 24 Jun 2011 10:23:19 -0300
From: Fernando Gont 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
MIME-Version: 1.0
To: Mark Smith 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org> <4E0401AD.8070108@gont.com.ar> <20110624135957.0664aa5e@opy.nosense.org>
In-Reply-To: <20110624135957.0664aa5e@opy.nosense.org>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 14:59:33 -0000

On 06/24/2011 01:29 AM, Mark Smith wrote:
> Actually it can.  Have a look at the following -
> 
> http://tools.ietf.org/html/draft-ietf-6man-dad-proxy-01
> 
> The layer 3 hub-and-spoke forwarding topology described can also be and
> is likely to also be enforced at layer 2, by preventing layer 2
> forwarding of traffic between designated host ports, limiting it to
> host port to router port, or router port to host port.

I think that deploying this only for dealing with ND-based attacks would
be overkill.

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  Fri Jun 24 08:04:59 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCBD21F8566; Fri, 24 Jun 2011 08:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.835
X-Spam-Level: 
X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfIkXzhJL+v0; Fri, 24 Jun 2011 08:04:59 -0700 (PDT)
Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by ietfa.amsl.com (Postfix) with ESMTP id 58AF221F8560; Fri, 24 Jun 2011 08:04:59 -0700 (PDT)
Received: from 114-30-114-141.ip.adam.com.au ([114.30.114.141] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Qa7wA-0003Tx-UP; Sat, 25 Jun 2011 00:34:50 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 49A243B341; Sat, 25 Jun 2011 00:34:50 +0930 (CST)
Date: Sat, 25 Jun 2011 00:34:50 +0930
From: Mark Smith 
To: Fernando Gont 
Message-ID: <20110625003450.6369ba85@opy.nosense.org>
In-Reply-To: <4E048FC7.5070706@gont.com.ar>
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>  <20110622210451.60ad8bce@opy.nosense.org> <4E0401AD.8070108@gont.com.ar> <20110624135957.0664aa5e@opy.nosense.org> <4E048FC7.5070706@gont.com.ar>
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; 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, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 15:05:00 -0000

On Fri, 24 Jun 2011 10:23:19 -0300
Fernando Gont  wrote:

> On 06/24/2011 01:29 AM, Mark Smith wrote:
> > Actually it can.  Have a look at the following -
> > 
> > http://tools.ietf.org/html/draft-ietf-6man-dad-proxy-01
> > 
> > The layer 3 hub-and-spoke forwarding topology described can also be and
> > is likely to also be enforced at layer 2, by preventing layer 2
> > forwarding of traffic between designated host ports, limiting it to
> > host port to router port, or router port to host port.
> 
> I think that deploying this only for dealing with ND-based attacks would
> be overkill.
> 

Depends on who you are.

> 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  Fri Jun 24 12:31:34 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB8711E80BE; Fri, 24 Jun 2011 12:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.473
X-Spam-Level: 
X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.126,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaMCpvYPryvZ; Fri, 24 Jun 2011 12:31:33 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE4511E8084; Fri, 24 Jun 2011 12:31:33 -0700 (PDT)
Received: by gya6 with SMTP id 6so1815589gya.31 for ; Fri, 24 Jun 2011 12:31:33 -0700 (PDT)
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:content-type:content-transfer-encoding; bh=GAImZqxfpNN3vuqn+gc3pmQSKKRQHQ3I80oybROUmUs=; b=OOE0xgCKqJSrt31JtUwlcoOvUbLupUiynAreUHAt3IaTuFsJQgkQB8S07+ksXEAt81 LuAcEo2dEfi2MKMxFW9vpBpvWNs9qjPVIGtVYCn0WFcsbBrZ5ak2w8VMkQA5+vgwpYS5 JlwoXsaKNHaBHOjgJhSgVSOsKFiTjw+tDTLjQ=
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:content-type :content-transfer-encoding; b=gqK+LZt4YvBtDOEmvWvDRpTB/oKC7EyeKbD8LZLL33U+QquNMzezc5FgMj/NVn7yXQ GBYi/kGqMWlzG+1gOVcAaZxcpnVT78lP595gLidKtLz2x+TSDF10UkGjX2seB3QD0oun cSyQbITvCSXXkRWmXS7Blek9DQNarqeftwVTQ=
Received: by 10.101.179.39 with SMTP id g39mr3974041anp.96.1308943892944; Fri, 24 Jun 2011 12:31:32 -0700 (PDT)
Received: from [192.168.123.103] ([190.48.229.153]) by mx.google.com with ESMTPS id c21sm2812391ana.50.2011.06.24.12.31.28 (version=SSLv3 cipher=OTHER); Fri, 24 Jun 2011 12:31:31 -0700 (PDT)
Sender: Fernando Gont 
Message-ID: <4E04E60E.7010808@gont.com.ar>
Date: Fri, 24 Jun 2011 16:31:26 -0300
From: Fernando Gont 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
MIME-Version: 1.0
To: Fred Baker 
References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com>	 
In-Reply-To: 
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: RJ Atkinson , v6ops@ietf.org, ipv6@ietf.org
Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 19:31:34 -0000

On 06/22/2011 05:04 PM, Fred Baker wrote:

>> From my perspective, the issue with the RA-Guard evasion draft
>> isn't that the faults are possible or that they are described; it's
>> that the description is specific to RA-Guard. In point of fact,
>> these kinds of attacks are true for any kind of firewall or other
>> middleware that has the notion of identifying a specific non-IP
>> packet and selectively do something to it. 

There some specific considerations for RA-Guard:

* RA-Guard has been specified, whereas firewall behaviour hasn't.

* Many networks employ DHCPv4-guard and/or arp-monitoring, and probably
expect to be able to do the same thing with IPv6 -- but these evasion
techniques apply only to the v6 case

* RA-Guard is implemented in layer-2 devices, where fragment reassembly
would be too onerous.


>> to eliminate pornography, Al-Queda literature, or dog racing should
>> be advised that overcoming that is as simple as https or obscure
>> fragmentation that splits a "GET" at a difficult place.

Parsing the app stream was already difficult with v4. Not being able to
even find the upper-layer header is new with v6.

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 fred@cisco.com  Fri Jun 24 14:10:47 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9930111E8084 for ; Fri, 24 Jun 2011 14:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.712
X-Spam-Level: 
X-Spam-Status: No, score=-110.712 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BmJChSL3wFY for ; Fri, 24 Jun 2011 14:10:46 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id A1C0B11E8073 for ; Fri, 24 Jun 2011 14:10:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=955; q=dns/txt; s=iport; t=1308949846; x=1310159446; h=from:subject:date:references:to:message-id:mime-version: content-transfer-encoding; bh=mMBXsASGXzAlg8O9wWtKnLIuAOqW758A8gSkFvESa4k=; b=iSBNmTBouH8iQS4yXSdiDB1t9j6NWdGZYpWEmCoXImEpuPU/Yt8u7TcD gOpnNvaQRm7xyrIEmER///kwBtrkHFqt6WayCwzHtF3r9Xusudp36RwBs QxsiE/dicLxagV+Ki5XHdXBF4UDBe6jjv8dSE431C1EfWA2IPeLkySfCe U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAP78BE6rRDoH/2dsb2JhbABTpz93iHOjDJ13hi0EhymKUoRoi0o
X-IronPort-AV: E=Sophos;i="4.65,421,1304294400"; d="scan'208";a="469652843"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 24 Jun 2011 21:10:46 +0000
Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5OL9pVi013879 for ; Fri, 24 Jun 2011 21:10:46 GMT
Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Fri, 24 Jun 2011 14:10:46 -0700
X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Fri, 24 Jun 2011 14:10:46 -0700
From: Fred Baker 
Date: Fri, 24 Jun 2011 14:10:45 -0700
References: <20110624183513.7035311E81A8@ietfa.amsl.com>
To: IPv6 Operations 
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [v6ops] Fwd: Please help the Nomcom
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 21:10:47 -0000

Begin forwarded message:

> From: NomCom Chair 
> Date: June 24, 2011 11:35:13 AM PDT
> To: Working Group Chairs 
> Subject: Please help the Nomcom 
> 
> Hi WG chairs,
>  We have had a good response to the first call for volunteers but the 
> rate at which new volunteers are coming in is slowing down. The Nomcom 
> process is best served by a large pool of volunteers drawn from a wide 
> spectrum of IETF attendees. Where else would we find this wide spectrum
> if not in the WG mailing lists.
> 
> I would really appreciate it if you can forward the message onto your
> working group mailing lists. 
> 
> The latest volunteer status and the second call for volunteers can be
> found at
> https://datatracker.ietf.org/ann/nomcom/2964/
> 
> Thanks in advance for your help.
> 
> Suresh Krishnan
> Nomcom Chair 2011-2012
> Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com


From fred@cisco.com  Wed Jun 29 03:51:54 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED5911E8075 for ; Wed, 29 Jun 2011 03:51:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEbxdR4E1Qaw for ; Wed, 29 Jun 2011 03:51:53 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id C9BD211E8070 for ; Wed, 29 Jun 2011 03:51:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=56; q=dns/txt; s=iport; t=1309344713; x=1310554313; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=7IQ3uKCiJV3JnMV3K6NXNfeiEllML8hast2FIvdGHYA=; b=bTlbyAaTJnbSgh7DM2/6k5fS9aw7pLM2Nwxb6Xq0Zvu2KDJwh4lhaLgJ b8kLQUa5L2BZGvccnrr3uUJ8W1t9lnxDiIUzI0PecWit7jPhoc4ctbULI VgixNZKLqCJMGhXynTWfjC9EWpHNnGWXZhSCoV+H8bZCB+DhslcdPaGQZ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EADYDC06tJV2Z/2dsb2JhbABSp1h3iHGgf4EenhiGMASSF5BG
X-IronPort-AV: E=Sophos;i="4.65,442,1304294400"; d="scan'208";a="349619539"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-3.cisco.com with ESMTP; 29 Jun 2011 10:51:53 +0000
Received: from jpannick-tmp9.cisco.com (rtp-vpn6-1598.cisco.com [10.82.254.68]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5TApqpW024775 for ; Wed, 29 Jun 2011 10:51:52 GMT
From: Fred Baker 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 29 Jun 2011 06:51:51 -0400
Message-Id: 
To: IPv6 Operations 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [v6ops] I-D cutoff
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 10:51:54 -0000

Reminder: the -00 draft cutoff for IETF 81 is Monday. 

From fred@cisco.com  Wed Jun 29 04:10:54 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C53921F86A7 for ; Wed, 29 Jun 2011 04:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.299
X-Spam-Level: 
X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USPPnnreBHR8 for ; Wed, 29 Jun 2011 04:10:48 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 53E0621F86A6 for ; Wed, 29 Jun 2011 04:10:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=13396; q=dns/txt; s=iport; t=1309345848; x=1310555448; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Sp+ZtXK8OZLEkEdyhP/jApaNzDtQ9VZdTX52HswqVX4=; b=i7I8bg9EW/398kp5fKMiAxDAnZAiTOrIIuicraq7HdFRojNt8XMXd62d 0M77OuqUgyy/5z/0oO8rhdRZOpxTxt83jcW+/2xVCYwVlCAWNxMI0ZHEd wikwUykz3tRy0jyytDKmJAbloRJ3Rdu4+DXEtGXk7zXxf06YZobSvgDmy U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAAcHC06tJXG//2dsb2JhbABEDqdYd4h4oXieG4MfE4J+BJIXiUGHBQ
X-IronPort-AV: E=Sophos;i="4.65,442,1304294400"; d="scan'208";a="723992211"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-6.cisco.com with ESMTP; 29 Jun 2011 11:10:46 +0000
Received: from jpannick-tmp9.cisco.com (rtp-vpn6-1598.cisco.com [10.82.254.68]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5TBAikA002087;  Wed, 29 Jun 2011 11:10:45 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Fred Baker 
In-Reply-To: <726788A8-AACA-45C1-AE89-12472D94DBFE@townsley.net>
Date: Wed, 29 Jun 2011 07:10:44 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <98D97264-A266-41FB-9913-A48A7105F73F@townsley.net> <726788A8-AACA-45C1-AE89-12472D94DBFE@townsley.net>
To: IPv6 Operations 
X-Mailer: Apple Mail (2.1084)
Subject: Re: [v6ops] [fun] status of the homenet effort
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 11:10:54 -0000

v6ops folks:

This may be of interest to those that have been involved in the CPE =
Router activity particularly and those interested generally in the =
issues of residential/SOHO equipment. It intersects with v6ops in the =
sense of including operational matters, but tends to be more in the =
customer of a broadband ISP than the ISP.

The list appears to be fun@ietf.org for the moment, but it may change to =
homenet. They tell me that someone will consolidate the lists if you're =
on them today.

On Jun 29, 2011, at 6:09 AM, Mark Townsley wrote:

>=20
> Fred, would you mind carrying this over to v6ops appropriately as a =
heads up and perhaps what it suggests in terms of current work in v6ops?
>=20
> Jari, when can we nail down the right list name? If that is imminent, =
perhaps Fred should wait until he can end the message with the right =
pointer.
>=20
> Thanks,
>=20
> - Mark
>=20
> Begin forwarded message:
>=20
>> From: Mark Townsley 
>> Date: June 29, 2011 11:46:03 AM GMT+02:00
>> To: fun@ietf.org, homegate@ietf.org
>> Subject: Re: [fun] status of the homenet effort
>>=20
>>=20
>> All,
>>=20
>> Apologies for double-posting if there are folks that are subscribed =
to homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone will =
finally create homenet@ietf.org and consolidate the membership =
accordingly.
>>=20
>> In the charter proposal below, I think you will see a lot of =
similarity with the consensus we achieved on the homegate list last =
year. Jari has taken that, feedback from the IESG, IAB, members of the =
IP-Directorate, v6ops chairs, etc. and shaped it towards something more =
focused on the Internet (and Routing) area, as well as IPv6. I believe =
he and Ralph both have a great deal of confidence that this is something =
that is very important to the industry, and that the IETF has a critical =
role to play.=20
>>=20
>> So, make no mistake, whether we end up as a WG or a BoF between now =
and Quebec, "we're back" - please send comments, and make your travel or =
remote-attendance plans accordingly if you want to participate.=20
>>=20
>> Jari has asked me to co-chair the session in Quebec. As such, I'd =
like to take requests for presentation time now. Jari and I will likely =
begin the session with a scoping overview, as well as a first cut at an =
architecture framework, but there should be some time for a few other =
items. When submitting your request, please identify which of the 5 =
areas below you think your work applies to as well as the =
internet-draft, of course.=20
>>=20
>> Thanks, and see you on the list and in Quebec.
>>=20
>> - Mark
>>=20
>>=20
>> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote:
>>=20
>>> I wanted to provide an update of the situation with this working =
group proposal.
>>>=20
>>> HOMENET is a new working group proposal, a variation of the =
HOMEGATE/HOMENET theme that we discussed last year, but this time =
looking at it from a different angle. The old effort was mostly focused =
about what home gateways should do: forwarding, transport, and DNS =
proxying issues. The new effort is about home networks themselves, in =
particular what kind of network architecture and configuration is =
necessary to support IPv6-based home networks. We view IPv4-based home =
networks as "done" at this time (or perhaps as "cannot be changed =
anyway").
>>>=20
>>> I have been discussing this effort in the background for the last =
couple of month with Mark Townsley and others, and more publicly since =
early June. The proposal has been brought to the IESG, IAB and some =
directorates for discussion, and we've been going back and forth whether =
this is ready to become a working group or needs to be run as a BOF in =
Quebec City. The current plan is that the working group proposal goes to =
IETF-wide review this week, and if the feedback from the community, IAB, =
and the IESG is positive, we will create the working group just in time =
for the IETF. Otherwise, the slot reserved in the agenda for the meeting =
will be used to run the proposal as a BOF.
>>>=20
>>> In any case, I would like to solicit discussion on this topic, and =
perhaps some early drafts as well. Please comment on the charter at =
least.
>>>=20
>>> Note that the new proposal was called FUN at the time that we =
created the list. It has now been renamed back to HOMENET to be more =
descriptive. The list will be renamed soon as well (current subscribers =
will stay).
>>>=20
>>> This is the most recent version of the charter we should discuss:
>>>=20
>>> Home Networks (homenet)
>>> -----------------------------------
>>>=20
>>> Current Status: Proposed
>>> Last Edit: Wednesday, June 29th, 2011
>>>=20
>>> Chairs:
>>> TBD
>>>=20
>>> Internet Area Directors:
>>> Ralph Droms 
>>> Jari Arkko 
>>>=20
>>> Internet Area Advisor:
>>> Jari Arkko 
>>>=20
>>> Routing Area Technical Advisor:
>>> TBD
>>>=20
>>> Security Area Technical Advisor:
>>> TBD
>>>=20
>>> Mailing Lists:
>>> General Discussion: fun@ietf.org
>>> To Subscribe: https://www.ietf.org/mailman/listinfo/fun
>>> Archive: http://www.ietf.org/mail-archive/web/fun
>>>=20
>>> Description of Working Group:
>>>=20
>>> This working group focuses on the evolving networking technology
>>> within and among relatively small =93residential home=94 networks. =
For
>>> example, an obvious trend in home networking is the proliferation of
>>> networking technology in an increasingly broad range and number of
>>> devices. This evolution in scale and diversity sets some =
requirements
>>> on IETF protocols. Some of the relevant trends include:
>>>=20
>>> o Multiple segments: While less complex L3-toplogies involving as =
few
>>> subnets as possible are preferred in home networks for a variety of
>>> reasons including simpler management and service discovery, the
>>> introduction of more than one subnet into a home network is enough
>>> to add complexity that needs to be addressed, and multiple
>>> dedicated segments are necessary for some cases. For instance, a
>>> common feature in modern home routers in the ability to support
>>> both guest and private network segments. Also, link layer
>>> networking technology is poised to become more heterogeneous, as
>>> networks begin to employ both traditional Ethernet technology and
>>> link layers designed for low-powered sensor networks. Finally,
>>> similar needs for segmentation may occur in other cases, such as
>>> separating building control or corporate extensions from the
>>> Internet access network. Different segments may be associated with
>>> subnets that have different routing and security policies.
>>>=20
>>> o Service providers are deploying IPv6, and support for IPv6 is
>>> increasingly available in home gateway devices. While IPv6 resembles
>>> IPv4 in many ways, it changes address allocation principles and =
allows
>>> direct IP addressability and routing to devices in the home from the
>>> Internet. This is a promising area in IPv6 that has proved =
challenging
>>> in IPv4 with the proliferation of NAT.
>>>=20
>>> o End-to-end communication is both an opportunity and a concern as =
it
>>> enables new applications but also exposes nodes in the internal
>>> networks to receipt of unwanted traffic from the Internet. Firewalls
>>> that restrict incoming connections may be used to prevent exposure,
>>> however, this reduces the efficacy of end-to-end connectivity that
>>> IPv6 has the potential to restore.
>>>=20
>>> Home networks need to provide the tools to handle these situations =
in
>>> a manner accessible to all users of home networks. Manual
>>> configuration is rarely, if at all, possible. The purpose of this
>>> working group is to focus on this evolution, in particular as it
>>> addresses the introduction of IPv6, by developing an architecture
>>> addressing this full scope of requirements:
>>>=20
>>> o prefix configuration for routers
>>> o managing routing
>>> o name resolution
>>> o service discovery
>>> o network security
>>>=20
>>> The task of the group is to produce an architecture document that
>>> outlines how to construct home networks involving multiple routers =
and
>>> subnets. This document is expected to apply the IPv6 addressing
>>> architecture, prefix delegation, global and ULA addresses, source
>>> address selection rules and other existing components of the IPv6
>>> architecture. The architecture document should drive what protocols
>>> changes, if any, are necessary. Specific protocol work described =
below
>>> is expected to be within the scope of the working group one the
>>> architecture work is complete. However, the group is required to
>>> review its charter and milestones with the IESG and IETF community
>>> before submitting documents that make protocol changes. It is =
expected
>>> that the group has to discuss some of the below solutions, however, =
in
>>> order to complete the architecture work.
>>>=20
>>> The group will apply existing protocols to handle the five
>>> requirements above. For prefix configuration, existing protocols are
>>> likely sufficient, and at worst may need some small enhancements, =
such
>>> as new options. For automatic routing, it is expected that existing
>>> routing protocols can be used as is, however, a new mechanism may be
>>> needed in order to turn a selected protocol on by default. For name
>>> resolution and service discovery, extensions to existing
>>> multicast-based name resolution protocols are needed to enable them =
to
>>> work across subnets.
>>>=20
>>> For network security, the group shall document the concept of
>>> "advanced security" as a further development of "simple security" =
from
>>> RFC 6092. The main goal of this work is to enable a security policy
>>> that adapts to IPv6 threats as they emerge, taking into account not
>>> only traffic from the Internet at large, but within and leaving the
>>> home network itself.
>>>=20
>>> It is expected that the working group will define a set of protocol
>>> specifications to accomplish the five requirements from
>>> above. However, it is not in the scope of the working group to =
define
>>> entirely new routing protocols or address allocation protocols. As
>>> noted, additional options or other small extensions may be necessary
>>> to use the existing protocols in these new configuration tasks. The
>>> working group shall also not make any changes to IPv6 protocols or
>>> addressing architecture. Prefix configuration, routing, and security
>>> related work shall not cause any changes that are not backwards
>>> compatible to existing IPv6 hosts. There may be host visible changes
>>> in the work on naming and discovery protocols, however. In its =
design,
>>> the working group shall also consider security aspects and the =
impact
>>> on manageability. The main focus of the working group is home
>>> networks, but the group's results may also find applications in =
other
>>> small networks.
>>>=20
>>> The working group will liaise with the relevant IETF working
>>> groups. In particular, the group should work closely with the V6OPS
>>> working group, review any use or extension of DHCP with the DHC
>>> working group, and work with additional DNS requirements with the
>>> DNSEXT and DNSOP working groups. If it turns out that additional
>>> options are needed for a routing protocol, they will be developed in
>>> the appropriate Routing Area working group, with the HOMENET working
>>> group providing the architecture and requirements for such
>>> enhancements. The working group will also liase with external
>>> standards bodies where it is expected that there are normative
>>> dependencies between the specifications of the two bodies.
>>> It is expected that in the architecture definition stage liaising
>>> with the Broadband Forum, DLNA, and UPnP Forum is necessary.
>>>=20
>>> Milestones:
>>>=20
>>> Jul 2011 Formation of the working group
>>> Sep 2011 First WG draft on the architecture
>>> Dec 2011 Submission of the architecture draft to the IESG as =
Informational RFC
>>> Dec 2011 Charter re-evaluation based on the architecture work
>>> Dec 2011 First WG draft on prefix configuration
>>> Dec 2011 First WG draft on routing
>>> Jan 2012 First WG draft on name resolution
>>> Feb 2012 First WG draft on service discovery
>>> Feb 2012 First WG draft on perimeter security
>>> Feb 2012 Start of routing related work in the relevant routing area =
working group, if needed
>>> Mar 2012 Submission of the prefix configuration draft to the IESG as =
Standards Track RFC
>>> Apr 2012 Submission of the routing draft to the IESG as =
Informational RFC
>>> Sep 2012 Submission of the name resolution draft to the IESG as =
Standards Track RFC
>>> Nov 2012 Submission of the service discovery draft to the IESG as =
Standards Track RFC
>>> Dec 2012 Submission of the perimeter security draft to the IESG as =
Informational RFC
>>>=20
>>> _______________________________________________
>>> fun mailing list
>>> fun@ietf.org
>>> https://www.ietf.org/mailman/listinfo/fun
>>=20
>=20


From jari.arkko@piuha.net  Wed Jun 29 14:30:20 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F3F21F84FF for ; Wed, 29 Jun 2011 14:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.068
X-Spam-Level: 
X-Spam-Status: No, score=-102.068 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKzjyTin-MXO for ; Wed, 29 Jun 2011 14:30:19 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 2208B21F84C6 for ; Wed, 29 Jun 2011 14:30:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4C65C2CC3B; Thu, 30 Jun 2011 00:30:18 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNa0UGndmerb; Thu, 30 Jun 2011 00:30:17 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 71CDF2CC39; Thu, 30 Jun 2011 00:30:17 +0300 (EEST)
Message-ID: <4E0B9969.7080402@piuha.net>
Date: Wed, 29 Jun 2011 23:30:17 +0200
From: Jari Arkko 
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: Fred Baker 
References: <98D97264-A266-41FB-9913-A48A7105F73F@townsley.net> <726788A8-AACA-45C1-AE89-12472D94DBFE@townsley.net> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IPv6 Operations 
Subject: Re: [v6ops] [fun] status of the homenet effort
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 21:30:20 -0000

Fred,

> This may be of interest to those that have been involved in the CPE Router activity particularly and those interested generally in the issues of residential/SOHO equipment. It intersects with v6ops in the sense of including operational matters, but tends to be more in the customer of a broadband ISP than the ISP.
>
> The list appears to be fun@ietf.org for the moment, but it may change to homenet. They tell me that someone will consolidate the lists if you're on them today.
>   

I would love to have V6OPS folks comment on this and join the work. You 
have been working in and around this space. The proposed working group 
would be a further expansion of these efforts, including the possibility 
of some specific protocol extensions that V6OPS has traditionally not 
been doing.

You can subscribe for the list at

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

but I have already asked for the list to be renamed to "homenet". All 
users who have subscribed to "fun" or who will be subscribing are going 
to be retained when the list rename is complete, so feel free to 
subscribe now. If the above link ceases to work, it means that the list 
rename has occurred. At that point you can access the list from

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

(Sorry for the name confusion, but I hope it will be sorted out soon.)

Jari


From joelja@bogus.com  Thu Jun 30 00:07:03 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FA011E813E; Thu, 30 Jun 2011 00:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.949
X-Spam-Level: 
X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFEXz6sil7fd; Thu, 30 Jun 2011 00:07:03 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 08EFF11E8074; Thu, 30 Jun 2011 00:07:02 -0700 (PDT)
Received: from zorch.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 p5U76xw0047171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Jun 2011 07:07:00 GMT (envelope-from joelja@bogus.com)
From: Joel Jaeggli 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 30 Jun 2011 00:06:59 -0700
Message-Id: 
To: ipv6@ietf.org, "v6ops@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 30 Jun 2011 07:07:00 +0000 (UTC)
Subject: [v6ops] new draft: draft-gashinsky-v6nd-enhance-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 07:07:03 -0000

I would direct the two working groups' attention if I may to a recently =
posted draft:

http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00

the potential DOS exposure that ipv6 neighbor discovery poses to routers =
is generally understood at this  point, the document covers usable work =
arounds, and includes some rough proposals for addressing what the =
authors views as shortcomings in the neighbor disocvery process.

some inspiration was drawn from:

http://tools.ietf.org/html/draft-nordmark-6man-impatient-nud-00

thanks
joel

A new version of I-D, draft-gashinsky-v6nd-enhance-00.txt has been =
successfully submitted by joel jaeggli and posted to the IETF =
repository.

Filename:	 draft-gashinsky-v6nd-enhance
Revision:	 00
Title:		 Operational Neighbor Discovery Problems and =
Enhancements.
Creation date:	 2011-06-29
WG ID:		 Individual Submission
Number of pages: 15

Abstract:
  In IPv4, subnets are generally small, made just large enough to cover
  the actual number of machines on the subnet.  In contrast, the
  default IPv6 subnet size is a /64, a number so large it covers
  trillions of addresses, the overwhelming number of which will be
  unassigned.  Consequently, simplistic implementations of Neighbor
  Discovery can be vulnerable to denial of service attacks whereby they
  attempt to perform address resolution for large numbers of unassigned
  addresses.  Such denial of attacks can be launched intentionally (by
  an attacker), or result from legitimate operational tools that scan
  networks for inventory and other purposes.  As a result of these
  vulnerabilities, new devices may not be able to "join" a =
network, it
  may be impossible to establish new IPv6 flows, and existing ipv6
  transported flows may be interrupted.

  This document describes the problem in detail and suggests possible
  implementation improvements as well as operational mitigation
  techniques that can in some cases to protect against such attacks.
  It also discusses possible modifications to the traditional [RFC4861]
  neighbor discovery protocol itself.




The IETF Secretariat

From fred@cisco.com  Thu Jun 30 06:55:15 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A66E11E810D for ; Thu, 30 Jun 2011 06:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10jzA5z3lKLA for ; Thu, 30 Jun 2011 06:55:14 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id C494211E80CB for ; Thu, 30 Jun 2011 06:55:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=144; q=dns/txt; s=iport; t=1309442110; x=1310651710; h=date:from:message-id:to:subject:cc; bh=X6j/64dC/BMpzG43bI381utdfF7o2/PegsXk00pViN4=; b=ZQ31YQV5SEyzBW8p3Jkc0ro24V/pFGIvidgqxBAADiGKO9QaMDxYpVM2 xrOeuLW3n+UStbn46a4tr6jb0Qd5CZrmRr4JS4Nna/ubdcTKIVbFu8v8T WW08pSitmQ1cb2zZvkNFd3rP6zxKwI2EwOtvJH7nChfD/5DIs7rLmJbh8 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtMHABCADE6rRDoG/2dsb2JhbABSmGQBAY5ud6o4nX6GMQSHQJs9
X-IronPort-AV: E=Sophos;i="4.65,450,1304294400"; d="scan'208";a="350579680"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 30 Jun 2011 13:55:01 +0000
Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5UDt1Cw013346; Thu, 30 Jun 2011 13:55:01 GMT
Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p5UDt1B28360; Thu, 30 Jun 2011 06:55:01 -0700 (PDT)
Date: Thu, 30 Jun 2011 06:55:01 -0700 (PDT)
From: 
Message-Id: <201106301355.p5UDt1B28360@ftpeng-update.cisco.com>
To: v6ops@ietf.org
Cc: draft-deng-v6ops-aplusp-experiment-results@tools.ietf.org
Subject: [v6ops] new draft: draft-deng-v6ops-aplusp-experiment-results-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 13:55:15 -0000

A new draft has been posted, at http://tools.ietf.org/html/draft-deng-v6ops-aplusp-experiment-results. Please take a look at it and comment.

From randy@psg.com  Thu Jun 30 23:22:52 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E1B228027 for ; Thu, 30 Jun 2011 23:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8tBEEuKrw+1 for ; Thu, 30 Jun 2011 23:22:52 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 438B4228006 for ; Thu, 30 Jun 2011 23:22:44 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QcX7g-0007yC-3X; Fri, 01 Jul 2011 06:22:40 +0000
Date: Fri, 01 Jul 2011 15:22:38 +0900
Message-ID: 
From: Randy Bush 
To: 
In-Reply-To: <201106301355.p5UDt1B28360@ftpeng-update.cisco.com>
References: <201106301355.p5UDt1B28360@ftpeng-update.cisco.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: v6ops@ietf.org, draft-deng-v6ops-aplusp-experiment-results@tools.ietf.org
Subject: Re: [v6ops] new draft: draft-deng-v6ops-aplusp-experiment-results-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Jul 2011 06:22:52 -0000

> draft-deng-v6ops-aplusp-experiment-results. Please take a look at it
> and comment.

really useful pragmatics

randy