From ichiroumakino@gmail.com Tue Feb 1 04:18:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F703A6AF1 for ; Tue, 1 Feb 2011 04:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ut4vR2gZ50nV for ; Tue, 1 Feb 2011 04:18:24 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id ECB973A69B8 for ; Tue, 1 Feb 2011 04:18:23 -0800 (PST) Received: by wwa36 with SMTP id 36so7418245wwa.13 for ; Tue, 01 Feb 2011 04:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=l40fB8VT1divKhW9XuhjWLlmLcnFIY5aOca9SA6c70U=; b=HdDWtwbukxQxmFM9JDBzXdE5VsYwtHpTpoGJntpLSY679dKc+p3ib6/XliTljQMI/b 3eaUgCSzPohuMQ3qH/TDAt3brQCzuoeq0+sD3gctKhQieiD1knfmWK6UH9xSioWbEKRx cuoPSvt667xol2A7et462wOA5zwgNVQQkCUr4= 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=Ml2ibAIKiXf1wHTN6/KyRyqLgPuE1r141smZq8x14NSUWlDg2nfTcwH0QdqCYDVxkz NvaicC58uJCtCFQOQGtClRnTAgJWM/mMw5SBy/xoYzjr3kYfCyoN0vTMpN5g+HCSrSnm pAvhUM5BFV8vTX17Y+FtjyvLzEh3E5RQTgejw= Received: by 10.216.160.129 with SMTP id u1mr516506wek.88.1296562892405; Tue, 01 Feb 2011 04:21:32 -0800 (PST) Received: from dhcp-osl-vl300-64-103-53-199.cisco.com (dhcp-osl-vl300-64-103-53-199.cisco.com [64.103.53.199]) by mx.google.com with ESMTPS id m50sm11408961wek.32.2011.02.01.04.21.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Feb 2011 04:21:30 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4D474C98.6000704@brightok.net> Date: Tue, 1 Feb 2011 13:21:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7386914F-9B5B-46EB-B2ED-1AB0156C9EC2@employees.org> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> <4D4723F5.9000201@brightok.net> <4D472B53.7080400@brightok.net> <86B22269-D7B6-4B1E-978F-51D719B2FB47@employees.org> <4D473262.8060109@brightok.net> <4D473EB9.6010802@brightok.net> <3F0BB162-030F-45EC-B430-9BA9C53A7439@employees.org> <4D474C98.6000704@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 12:18:25 -0000 Jack, > Honestly, I want off the shelf multi vendor CPEs that I can stack in = any combination or order, they handle numbering by themselves, they = agree on firewall rules by themselves, and they provide me an easy mDNS = selectable interface for connecting to all the management interfaces. = Knowing my customers, they want the same thing; plug it in somewhere and = it should work (and they really wish if they plugged the DSL modem into = a LAN port accidentally, that the router would just work). +1. that in my mind requires: - unicast and multicast routing in the home - "border detection". a router knows internal and external interfaces - service discovery of a wider scope than link-local - distribution of other configuration information - prefix and address assignment (e.g. zOSPF or similar) pretty much see the proposed homenet WG charter proposal. cheers, Ole From fred@cisco.com Tue Feb 1 07:00:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16B003A6D23 for ; Tue, 1 Feb 2011 07:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.307 X-Spam-Level: X-Spam-Status: No, score=-110.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyyKWPVay1cR for ; Tue, 1 Feb 2011 07:00:12 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id F16DC3A6D20 for ; Tue, 1 Feb 2011 07:00:11 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgEAHSvR02Q/khNgWdsb2JhbAClBRUBARYiJKERmx6FUwSMI4NC Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 01 Feb 2011 15:03:28 +0000 Received: from [10.35.8.22] (ams3-vpn-dhcp5890.cisco.com [10.61.87.1]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p11F3SS4008513; Tue, 1 Feb 2011 15:03:28 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4D472B53.7080400@brightok.net> Date: Tue, 1 Feb 2011 15:03:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <13AD18F7-2315-4E7E-A4DB-C8BFBEA8CC7C@cisco.com> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> <4D4723F5.9000201@brightok.net> <4D472B53.7080400@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 15:00:13 -0000 On Jan 31, 2011, at 9:36 PM, Jack Bates wrote: > On 1/31/2011 3:29 PM, Ole Troan wrote: >> one where there is no administrative boundary between the customer >> and the provider you mean? this solution should also handle the case >> where the end user network is connected to multiple providers. >>=20 >=20 > To be honest, there is no administrative boundary in zeroconf CPEs = today. Boundaries only form when a customer starts to actually manage = their CPE. My only issue is that the current model forces the ISP to do = one of two things: >=20 > 1) Restrict all customers to a single routed CPE interfacing with the = ISP (here's your /48, /56, etc but only one) >=20 > 2) Issue longer prefixes and more of them to the CPE in an on-demand = scenario (okay, you've issued 6 /64 requests, and I'll answer those up = to 20, then I say you're done). >=20 > The first is the better option of the 2, but it continues to restrict = the provider/customer interface in ways that are not desirable. I find this statement really surprising. It conflates allocation with = routing. It seems to me that if a downstream network had N>1 interfaces to a = given upstream and got a prefix (/44, /63, whatever) from it, the = upstream would normally consider that it could route the entire prefix = to each of the N interfaces according to whatever rules it chose, and = the downstream could allocate /64s within the prefix as it chose. In = other words, it would operate the same way that it would operate if the = downstream had PI space with the exception that the upstream wouldn't = advertise the more specific route - it would merely announce its own = much-shorter prefix.= From jbates@brightok.net Tue Feb 1 07:35:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F11E3A6C1A for ; Tue, 1 Feb 2011 07:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSk-NWdXnWPF for ; Tue, 1 Feb 2011 07:35:16 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 65DC53A6C0F for ; Tue, 1 Feb 2011 07:35:16 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p11FcVN1013529; Tue, 1 Feb 2011 09:38:31 -0600 (CST) Message-ID: <4D4828F6.50201@brightok.net> Date: Tue, 01 Feb 2011 09:38:30 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> <4D4723F5.9000201@brightok.net> <4D472B53.7080400@brightok.net> <13AD18F7-2315-4E7E-A4DB-C8BFBEA8CC7C@cisco.com> In-Reply-To: <13AD18F7-2315-4E7E-A4DB-C8BFBEA8CC7C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 15:35:17 -0000 On 2/1/2011 9:03 AM, Fred Baker wrote: > the upstream would normally consider that it could route the entire > prefix to each of the N interfaces according to whatever rules it > chose, and the downstream could allocate /64s within the prefix as it > chose. In other words, it would operate the same way that it would > operate if the downstream had PI space with the exception that the > upstream wouldn't advertise the more specific route - it would merely > announce its own much-shorter prefix. My problem with this, is that there's no guarantee that the N interfaces share any routing information between them. It's a generic home network. What always gets me is that implementations I've seen treat DHCPv6-PD as individual prefixes without a concept of reserving space and issuing needed space out of it. I have no problem routing a /48 to a customer CPE. The problem isn't the educated. The problem is the ability to configure a SP edge to allow any number of configurations in a home network and just allow it to work. Yes, there's alternatives, such as CPE standards perhaps recognizing each other even on the wan and splitting address space. The whole mechanism could be done in a CPE, but whatever method is chose, it should be pushed forward and mandated as support for zeroconf. We are quickly on the way to returning to the original days of when buying a CPE required a lot of manual configuration, when IPv6 has the capability of doing so much more. Jack From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Feb 1 12:13:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EE8B3A6C7C for ; Tue, 1 Feb 2011 12:13:31 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8USzQpC5qxD for ; Tue, 1 Feb 2011 12:13:30 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 048DA3A6C7D for ; Tue, 1 Feb 2011 12:13:29 -0800 (PST) Received: from 114-30-114-29.ip.adam.com.au ([114.30.114.29] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PkMeY-0001Eo-Qc; Wed, 02 Feb 2011 06:46:42 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 18E393B336; Wed, 2 Feb 2011 06:46:42 +1030 (CST) Date: Wed, 2 Feb 2011 06:46:41 +1030 From: Mark Smith To: Jack Bates Message-ID: <20110202064641.0e2e5ad1@opy.nosense.org> In-Reply-To: <4D4737F8.3090105@brightok.net> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <4D46F5BD.2050704@brightok.net> <20110201073623.5628b0b9@opy.nosense.org> <4D472E95.4030506@gmail.com> <9C882D91-A6AF-43BC-A5D8-E7A5B44B78E2@gmail.com> <4D4737F8.3090105@brightok.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 20:13:31 -0000 On Mon, 31 Jan 2011 16:30:16 -0600 Jack Bates wrote: > > > On 1/31/2011 4:14 PM, Michael Newbery wrote: > > +1. While a fully managed service is something that a customer may > > wish to purchase, that's a whole different service to the normal ISP > > case, and keeping a clean demarcation only enhances even a fully > > managed service offering. > > You've also broken a good portion of my customers if they left > everything plugged in as is and could upgrade their routers to IPv6 (or > I'll be issuing 2-8 /48's for a single customer, as it's not uncommon > for multiple routers to be connected into the ISP bridging modem, or > even a switch connected to the modem with a string of routers connected > to it) > > We're not talking about changing the demarcation. We're talking about > the ability separate allocation to customer from delegation to a router. > More specifically, multiple routers, in an automated fashion. There's no > additional tracking concerns. > > 1) Customer has 1 router and it has 1 or more delegations inside of an > allocation which can all be summaries as an aggregate. > > 2) Customer has multiple routers and it has multiple delegations inside > of an allocation which can be summaries as a group of aggregates if you > need specific router information or as the entire allocation if you only > care about the specific customer. > The issue with this second model is that a multihomed CPE or multiple CPE scenario isn't in scope for the simple CPE draft, and trying to address it in the simple CPE draft at this time would only further delay its publication. In the longer term, dynamic multihoming would be useful, and may become far more popular. However, I think it is important to soon have an RFC that describes the IPv6 equivalent of the most commonly deployed IPv4 scenario today, which is the single CPE, single homed scenario. > I'm not saying that everyone will agree with the model. Yet, to not even > support the model? Is there another model you have for supporting this > without issuing longer prefixes which can lower the depth of the > customer network? > > Jack > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jason_livingood@cable.comcast.com Tue Feb 1 14:54:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928C23A6C9E for ; Tue, 1 Feb 2011 14:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=1.877, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEHKqDw07Z9B for ; Tue, 1 Feb 2011 14:54:05 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id DDDE83A6CA6 for ; Tue, 1 Feb 2011 14:54:04 -0800 (PST) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.112423042; Tue, 01 Feb 2011 17:57:19 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Tue, 1 Feb 2011 17:57:16 -0500 From: "Livingood, Jason" To: "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01 Thread-Index: AQHLvNRqPcxWdjbsU0G4DnccijWfJZPtS1GA Date: Tue, 1 Feb 2011 22:57:15 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.11] Content-Type: multipart/alternative; boundary="_000_C96DF7D4169ADjasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: Re: [v6ops] draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 22:54:06 -0000 --_000_C96DF7D4169ADjasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I received some markup from John Brzozowski after the last IETF as well, an= d I have just finished incorporating that into the document now. This is th= e last bit of feedback that I had in my queue from the IETF meeting and lis= t traffic to deal with and I should then have all the open issue closed. If anyone has not yet sent feedback or received an email from me responding= to a comment/change request, please send me an email ASAP. Before the end of the week, I will be posting a =9602 version of the docume= nt and I think at that point I'll be ready for a last call. Thanks! Jason On 1/25/11 4:11 PM, "Livingood, Jason" > wrote: All =96 Momentarily I will post a new version of this draft, -01, for WG fe= edback. I expect to receive some feedback and quickly incorporate that into= a =9602 which will then hopefully be mature enough to stand for a WGLC. In any case, I will send a few emails related to this draft today. Each wil= l address a specific issue that I am looking for either feedback on or revi= ew of in some manner. I decided to send separate emails as it will make it = easier for me to parse the feedback and make rapid changes. Thanks in advace! Jason --_000_C96DF7D4169ADjasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I received some markup from John Brzozowski after the last IETF as wel= l, and I have just finished incorporating that into the document now. This = is the last bit of feedback that I had in my queue from the IETF meeting an= d list traffic to deal with and I should then have all the open issue closed. 

If anyone has not yet sent feedback or received an email from me respo= nding to a comment/change request, please send me an email ASAP.

Before the end of the week, I will be posting a =9602 version of the d= ocument and I think at that point I'll be ready for a last call.

Thanks!
Jason


On 1/25/11 4:11 PM, "Livingood, Jason" <jason_livingood@cable.comcast.com&g= t; wrote:

All =96 Momentarily I will post a new version of this draft, -01, for = WG feedback. I expect to receive some feedback and quickly incorporate that= into a =9602 which will then hopefully be mature enough to stand for a WGL= C.

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

Thanks in advace!
Jason
 --_000_C96DF7D4169ADjasonlivingoodcablecomcastcom_-- From lee@asgard.org Tue Feb 1 16:24:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585C93A6B88 for ; Tue, 1 Feb 2011 16:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkGPmvlHlkUv for ; Tue, 1 Feb 2011 16:24:39 -0800 (PST) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by core3.amsl.com (Postfix) with ESMTP id 011F13A6B26 for ; Tue, 1 Feb 2011 16:24:38 -0800 (PST) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p120Rua4010983 for ; Tue, 1 Feb 2011 19:27:56 -0500 Authentication-Results: cm-omr3 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.160] ([204.235.115.160:37608] helo=HDC00027112) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 3E/0B-07458-C05A84D4; Tue, 01 Feb 2011 19:27:56 -0500 From: "Lee Howard" To: "'Jack Bates'" , "'Michael Newbery'" References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <4D46F5BD.2050704@brightok.net> <20110201073623.5628b0b9@opy.nosense.org> <4D472E95.4030506@gmail.com> <9C882D91-A6AF-43BC-A5D8-E7A5B44B78E2@gmail.com> <4D4737F8.3090105@brightok.net> In-Reply-To: <4D4737F8.3090105@brightok.net> Date: Tue, 1 Feb 2011 19:27:55 -0500 Message-ID: <005601cbc270$09d65c00$1d831400$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvBlnJ5gd1puRc9TX20lr4S9NdF0wA2F0oQ Content-Language: en-us Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 00:24:40 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Jack Bates > > You've also broken a good portion of my customers if they left > everything plugged in as is and could upgrade their routers to IPv6 (or > I'll be issuing 2-8 /48's for a single customer, as it's not uncommon > for multiple routers to be connected into the ISP bridging modem, or > even a switch connected to the modem with a string of routers connected > to it) That's not uncommon? To me, that's unheard of in a " residential or small office router." If the problem statement is, "We need to define behavior for a device that supports an arbitrary number of instances in an arbitrary topology with an arbitrary number of connections without requiring management or configuration, and for less than $50USD," then we have scoped ourselves beyond the possible. Issue multiple prefixes per customer, if you support multiple routers. If you don't like the prefix length, change it. Lee From jbates@brightok.net Tue Feb 1 17:09:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2DFB3A6CB6 for ; Tue, 1 Feb 2011 17:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svq8BiqS1yl4 for ; Tue, 1 Feb 2011 17:09:16 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 5C1EB3A6CA8 for ; Tue, 1 Feb 2011 17:09:16 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p121CWLr000158; Tue, 1 Feb 2011 19:12:32 -0600 (CST) Message-ID: <4D48AF72.9020805@brightok.net> Date: Tue, 01 Feb 2011 19:12:18 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lee Howard References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <4D46F5BD.2050704@brightok.net> <20110201073623.5628b0b9@opy.nosense.org> <4D472E95.4030506@gmail.com> <9C882D91-A6AF-43BC-A5D8-E7A5B44B78E2@gmail.com> <4D4737F8.3090105@brightok.net> <005601cbc270$09d65c00$1d831400$@org> In-Reply-To: <005601cbc270$09d65c00$1d831400$@org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 01:09:17 -0000 On 2/1/2011 6:27 PM, Lee Howard wrote: > If the problem statement is, "We need to define behavior for a device > that supports an arbitrary number of instances in an arbitrary topology > with an arbitrary number of connections without requiring management > or configuration, and for less than $50USD," then we have scoped > ourselves beyond the possible. > How have we scoped ourselves beyond the possible? You write the standard for the protocols. Vendors implement the protocols. Many vendors have shared code from chip manufacturers, so I don't really see an issue here. Provide the guidance for it to happen, they'll implement it. Nothing I've suggested will consume a lot of memory or flash (the major pricing points). More importantly, it's a matter of properly addressing the entire problem caused by shifting from IPv4 with NAPTv4 into IPv6 with DHCPv6-PD. > Issue multiple prefixes per customer, if you support multiple routers. If > you don't like the prefix length, change it. > The problem is, the desired goal is to look at assigning a single /48 per site, and being able to support that site. My original viewpoint on the problem was that the ISP layer can actually handle some of this versatility. Most of it could be developed as a CPE protocol to handle sharing of addressing even via the WAN interface. However, a protocol of that scope will require even more work on the part of the CPE. I was trying to develop a method that: 1) better utilizes the existing protocols 2) changes things closer to implementation level than the actual protocols themselves 3) defines logic and methodology which currently isn't documented or standardized. 4) focuses on what works best in CPE PD handling first, treating support at the ISP level as a secondary option, but not required (ie, a CPE plugged into another CPE should just work and needs to be addressed, but how a CPE treats assignments should also be supported at the ISP level as an option). We cannot leave chained DHCPv6-PD issues unresolved. There needs to be a standard for that. Applying similar logic up to the ISP level is also prudent, for those ISPs which do which to offer such services to their customers and to insure interoperability. As it stands, IPv6 cpe routers are likely to only be interoperable in a single configuration: ISP -> CPE -> HOST This is a step back from what we support in IPv4. Jack From Internet-Drafts@ietf.org Tue Feb 1 17:45:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CDF73A711B; Tue, 1 Feb 2011 17:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5mmp4KqI23X; Tue, 1 Feb 2011 17:45:04 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2053A70F8; Tue, 1 Feb 2011 17:45:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110202014503.11908.84576.idtracker@localhost> Date: Tue, 01 Feb 2011 17:45:03 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-v4v6tran-framework-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 01:45:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Framework for IP Version Transition Scenarios Author(s) : B. Carpenter, et al. Filename : draft-ietf-v6ops-v4v6tran-framework-01.txt Pages : 7 Date : 2011-02-01 This document sets out a framework for the presentation of scenarios and recommendations for a variety of approaches to the transition from IPv4 to IPv6, given the necessity for a long period of co- existence of the two protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v4v6tran-framework-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-v4v6tran-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-01173142.I-D@ietf.org> --NextPart-- From brian.e.carpenter@gmail.com Tue Feb 1 17:58:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32593A6CAC for ; Tue, 1 Feb 2011 17:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.444 X-Spam-Level: X-Spam-Status: No, score=-103.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7F97LZrgybxo for ; Tue, 1 Feb 2011 17:58:45 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id BD2213A6915 for ; Tue, 1 Feb 2011 17:58:44 -0800 (PST) Received: by ewy8 with SMTP id 8so3917771ewy.31 for ; Tue, 01 Feb 2011 18:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=juqNpp0SdxP+2ke+bud5jVTuwa+fiM+E+bTHoqZ4hd0=; b=ujOj6KcVsfMtYSX9Qpt7oRRT9/DBGovoaeXjmkb9oD6oJCLYRq7XhrU7gOkOAFFMrI 8ayTzqojEXnIm7hfu8orjvmceQ813E7DMNLywxbDgZIJL1u5MDKSvhuVSbt6Hr3vsGzN Ar1pH2VtEzEMymuBH/gYnxC2LvauDI2xnwbfo= 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=rztarbr7tbSWGKqw5/9gwqqP+gmv++U33snrz1Z4owEPzV6eF0ZUHbeR2E2AT6hyE1 qHfZLHH02c/jVHLOQxAfbqhGeCmUQol8RYyT9LoRjtdODkc1gWC0WIxuNFmZhUnM2taN f7aUm68ZyA8wCmvl39/qv6DnKvYuDBKQIv7T0= Received: by 10.213.7.138 with SMTP id d10mr2533833ebd.55.1296612121564; Tue, 01 Feb 2011 18:02:01 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id x54sm17804237eeh.11.2011.02.01.18.01.59 (version=SSLv3 cipher=RC4-MD5); Tue, 01 Feb 2011 18:02:00 -0800 (PST) Message-ID: <4D48BB1E.7050407@gmail.com> Date: Wed, 02 Feb 2011 15:02:06 +1300 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=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] [Fwd: I-D Action:draft-ietf-v6ops-v4v6tran-framework-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 01:58:45 -0000 This is a very small update as promised in the WGLC message. -------- Original Message -------- Subject: I-D Action:draft-ietf-v6ops-v4v6tran-framework-01.txt Date: Tue, 01 Feb 2011 17:45:03 -0800 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 : Framework for IP Version Transition Scenarios Author(s) : B. Carpenter, et al. Filename : draft-ietf-v6ops-v4v6tran-framework-01.txt Pages : 7 Date : 2011-02-01 This document sets out a framework for the presentation of scenarios and recommendations for a variety of approaches to the transition from IPv4 to IPv6, given the necessity for a long period of co- existence of the two protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v4v6tran-framework-01.txt From martin@millnert.se Tue Feb 1 18:58:32 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21AD03A711A for ; Tue, 1 Feb 2011 18:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmWZVXGIfU9o for ; Tue, 1 Feb 2011 18:58:31 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by core3.amsl.com (Postfix) with ESMTP id 373943A6BB6 for ; Tue, 1 Feb 2011 18:58:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 468657797; Wed, 2 Feb 2011 04:05:44 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR-OF2x32cZQ; Wed, 2 Feb 2011 04:05:44 +0100 (CET) Received: from [192.168.1.135] (c-24-147-137-106.hsd1.ma.comcast.net [24.147.137.106]) by ncis.csbnet.se (Postfix) with ESMTPSA id 2821D7756; Wed, 2 Feb 2011 04:05:42 +0100 (CET) From: Martin Millnert To: "Livingood, Jason" In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Feb 2011 22:01:43 -0500 Message-ID: <1296615703.3760.3.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] v6-aaaa-whitelisting-implications -- Recommended Practice? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 02:58:32 -0000 Jason, On Mon, 2011-01-31 at 19:13 +0000, Livingood, Jason wrote: > Thanks for the feedback, and for the reference suggested at the end. I'll > add that to the -02 update, as well ensure that any speculation is > explicitly described as such. > > BTW, based on your email, sounds like good input for an "Objectives for > World IPv6 Day" document! A friend pointed out to me recently the logical fallacy in what I was suggesting the other day: It is impossible to measure how many Internet hosts can/can't reach you because you have a AAAA on, ... when you have a AAAA on. Oops. I guess we will have to make do with some keeping our ears out for unusual problems reported to ISPs support desks and similar L8-expressions of brokenness. Cheers, Martin From fred@cisco.com Tue Feb 1 23:29:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ECBE3A6CAC for ; Tue, 1 Feb 2011 23:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.049 X-Spam-Level: X-Spam-Status: No, score=-110.049 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oK4BbiI+T1z4 for ; Tue, 1 Feb 2011 23:29:32 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 684463A6C00 for ; Tue, 1 Feb 2011 23:29:32 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMEAAKXSE2Q/khLgWdsb2JhbAClFxUBARYiJKE8mxCFUwSLX4Mp Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 02 Feb 2011 07:32:50 +0000 Received: from [192.168.12.236] (dhcp-10-61-102-184.cisco.com [10.61.102.184]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p127WoCe019649; Wed, 2 Feb 2011 07:32:50 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4D48BB1E.7050407@gmail.com> Date: Wed, 2 Feb 2011 07:32:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D48BB1E.7050407@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-ietf-v6ops-v4v6tran-framework-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 07:29:33 -0000 THanks On Feb 2, 2011, at 2:02 AM, Brian E Carpenter wrote: > This is a very small update as promised in the WGLC message. >=20 > -------- Original Message -------- > Subject: I-D Action:draft-ietf-v6ops-v4v6tran-framework-01.txt > Date: Tue, 01 Feb 2011 17:45:03 -0800 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: v6ops@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations Working Group of the = IETF. >=20 >=20 > Title : Framework for IP Version Transition Scenarios > Author(s) : B. Carpenter, et al. > Filename : draft-ietf-v6ops-v4v6tran-framework-01.txt > Pages : 7 > Date : 2011-02-01 >=20 > This document sets out a framework for the presentation of scenarios > and recommendations for a variety of approaches to the transition > from IPv4 to IPv6, given the necessity for a long period of co- > existence of the two protocols. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v4v6tran-framework-01= .txt >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Wed Feb 2 19:38:54 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2DA3A67C3 for ; Wed, 2 Feb 2011 19:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.442 X-Spam-Level: X-Spam-Status: No, score=-103.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuhJ+WkFMeof for ; Wed, 2 Feb 2011 19:38:53 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id B7A353A67B4 for ; Wed, 2 Feb 2011 19:38:53 -0800 (PST) Received: by qwi2 with SMTP id 2so682114qwi.31 for ; Wed, 02 Feb 2011 19:42:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=rapeWDHaDSa9Tvy8hq8w2MivTMNP7ENBBD5UErtarBc=; b=HJazTSoqVEVgY2MS3xHW3O5WRVEUhrwDvCSJ9dJnI6L/PNnSgMq7HkKOkMe6KKhEwW wAfQIZDr69Z7iHGBlF+WRDH2Zh6jQHnYy7ohr2JssXJFzADwmFmyY3sqVR5pYIMqxpAz tTgo7uJHF+FJ1PpNTT08LKLqjnchgX0+r/Zz0= 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=VRq4Ec8FMbRrgiRtdWhCOSfftwv78uYhEFgD6+iJaksZI3xHHUbLKaJpxeEUVWv0/D fe1fpEnjOpM8H3xu1ez5WF98aQh1lmMIaprotsIhT8sPut1Xb7tatkhQ9URGBeWCSCSj mxMcG9/YYGZFAcutZo4BgSIfNsG/iMxWYA05I= Received: by 10.229.235.4 with SMTP id ke4mr9022868qcb.63.1296704533292; Wed, 02 Feb 2011 19:42:13 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id p13sm289595qcu.5.2011.02.02.19.42.11 (version=SSLv3 cipher=RC4-MD5); Wed, 02 Feb 2011 19:42:12 -0800 (PST) Message-ID: <4D4A2401.2020500@gmail.com> Date: Thu, 03 Feb 2011 16:41:53 +1300 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=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 03:38:54 -0000 Hi, This may be of interest. It's incomplete pending a co-author contribution due soon, but there has been quite a bit of off-list discussion so I though it was time to post the rough draft. Brian -------- Original Message -------- Subject: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt Date: Wed, 02 Feb 2011 19:30:01 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Advisory Guidelines for 6to4 and Teredo Deployment Author(s) : B. Carpenter Filename : draft-carpenter-v6ops-6to4-teredo-advisory-00.txt Pages : 16 Date : 2011-02-02 This document provides advice to network operators about deployment of two techniques for automatic tunneling of IPv6 over IPv4, namely 6to4 and Teredo. It is principally addressed to Internet Service Providers, including those that do not yet support IPv6, and to Content Providers. 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-carpenter-v6ops-6to4-teredo-advisory-00.txt From ichiroumakino@gmail.com Thu Feb 3 06:08:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A369F3A68CF for ; Thu, 3 Feb 2011 06:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.213 X-Spam-Level: X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBVTtIXhjezj for ; Thu, 3 Feb 2011 06:08:52 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 8AF083A67D9 for ; Thu, 3 Feb 2011 06:08:52 -0800 (PST) Received: by ewy8 with SMTP id 8so667736ewy.31 for ; Thu, 03 Feb 2011 06:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=vuwSzD6vE765PQqIygM/zsgWcE2K/42dEMgWcPIt4g0=; b=vw/m+0L6PA0ugqDYS57r/tKuT/e/qiznsSisMo89EuedxjjnVoMEnG42qn0gK3TD++ oMZlpsCA2iTzuVIj8gsdOw1xKZfC/rtKo8n95KVcRAJ4+Jtd377SaRu/KYvdOc7sBR/o bWsOlKm7XtbLDDKWMTkDZ0iiv3f1ssfkyKJAg= 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=erj6jz6nByPz4BJlPU9HGifNLv2PNtWVb2EAtEgW3X5cuxeMOal/WE1ED0wJkuJ/16 21dEoctIJhHE/MCuIoTDOVPLtmaVZCO4D4BihJdWsjnZCqqSEZdE/n7vFKvX6Zd3YeEV 7qhc+H8pFEwNgySMYmxqiSwf/KN4+FFC3Uio4= Received: by 10.213.22.133 with SMTP id n5mr13645579ebb.39.1296742333511; Thu, 03 Feb 2011 06:12:13 -0800 (PST) Received: from gomlefisk.cisco.com (146.84-48-213.nextgentel.com [84.48.213.146]) by mx.google.com with ESMTPS id q52sm662036eei.9.2011.02.03.06.12.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 06:12:12 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4D4A2401.2020500@gmail.com> Date: Thu, 3 Feb 2011 15:12:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> References: <4D4A2401.2020500@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 14:08:53 -0000 Brian, > This may be of interest. It's incomplete pending a co-author = contribution > due soon, but there has been quite a bit of off-list discussion so > I though it was time to post the rough draft. excellent draft and good recommendations. do you only want recommendations to operators or also to vendors? e.g. I would have liked: - 6to4 MUST not be enabled by default - 6to4 SHOULD use a periodic reachability test to the relay similar to = what is specified in RFC5969 - 6to4/Teredo MUST by default be at the least preferred option in = SAS/DAS selection policy. i.e. prefer NATed IPv4 over 6to4/Teredo - for networks that want to stop 6to4/Teredo traffic. a captive portal = could be used to make users aware that they are using Teredo/6to4 and be = given instructions for how to turn it off. cheers, Ole > -------- Original Message -------- > Subject: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt > Date: Wed, 02 Feb 2011 19:30:01 -0800 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Advisory Guidelines for 6to4 and Teredo = Deployment > Author(s) : B. Carpenter > Filename : = draft-carpenter-v6ops-6to4-teredo-advisory-00.txt > Pages : 16 > Date : 2011-02-02 >=20 > This document provides advice to network operators about deployment > of two techniques for automatic tunneling of IPv6 over IPv4, namely > 6to4 and Teredo. It is principally addressed to Internet Service > Providers, including those that do not yet support IPv6, and to > Content Providers. The intention of the advice is to minimise both > user dissatisfaction and help desk calls. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-6to4-teredo-advi= sory-00.txt >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From sander@steffann.nl Thu Feb 3 06:33:18 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8258D3A6973 for ; Thu, 3 Feb 2011 06:33:18 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R99Bf3yFUAM6 for ; Thu, 3 Feb 2011 06:33:17 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by core3.amsl.com (Postfix) with ESMTP id 52CD33A67EB for ; Thu, 3 Feb 2011 06:33:17 -0800 (PST) Received: from macpro.10ww.steffann.nl (unknown [IPv6:2001:610:6ce:1:224:36ff:feef:1d89]) by mail.sintact.nl (Postfix) with ESMTP id 8F9A92051; Thu, 3 Feb 2011 15:36:38 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> Date: Thu, 3 Feb 2011 15:36:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 14:33:18 -0000 Hi, > excellent draft and good recommendations. >=20 > do you only want recommendations to operators or also to vendors? > e.g. I would have liked: >=20 > - 6to4 MUST not be enabled by default > - 6to4 SHOULD use a periodic reachability test to the relay similar to = what is specified in RFC5969 > - 6to4/Teredo MUST by default be at the least preferred option in = SAS/DAS selection policy. i.e. prefer NATed IPv4 over 6to4/Teredo >=20 > - for networks that want to stop 6to4/Teredo traffic. a captive portal = could be used to make users aware that they are using Teredo/6to4 and be = given instructions for how to turn it off. I agree with these suggestions. It would be good to include them. Thanks, Sander From jbates@brightok.net Thu Feb 3 07:48:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B23B3A67EB for ; Thu, 3 Feb 2011 07:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4zFZMKf7bVL for ; Thu, 3 Feb 2011 07:48:01 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 89A283A69BA for ; Thu, 3 Feb 2011 07:48:01 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p13FpMBv013851; Thu, 3 Feb 2011 09:51:22 -0600 (CST) Message-ID: <4D4ACEFA.3080106@brightok.net> Date: Thu, 03 Feb 2011 09:51:22 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sander Steffann References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> In-Reply-To: <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 15:48:02 -0000 On 2/3/2011 8:36 AM, Sander Steffann wrote: > - 6to4 MUST not be enabled by default >> - 6to4 SHOULD use a periodic reachability test to the relay similar to what is specified in RFC5969 Wouldn't these be reversed? If you mandate a reachability test to make sure the 6to4 is valid, there's no problem with it enabled by default. Jack From sander@steffann.nl Thu Feb 3 07:51:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10253A69DD for ; Thu, 3 Feb 2011 07:51:15 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neyg-u99QOi0 for ; Thu, 3 Feb 2011 07:51:14 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by core3.amsl.com (Postfix) with ESMTP id 716423A69E0 for ; Thu, 3 Feb 2011 07:51:13 -0800 (PST) Received: from macpro.10ww.steffann.nl (unknown [IPv6:2001:610:6ce:1:224:36ff:feef:1d89]) by mail.sintact.nl (Postfix) with ESMTP id 5C8EA2005; Thu, 3 Feb 2011 16:54:35 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: <4D4ACEFA.3080106@brightok.net> Date: Thu, 3 Feb 2011 16:54:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 15:51:15 -0000 Hi, > On 2/3/2011 8:36 AM, Sander Steffann wrote: >> - 6to4 MUST not be enabled by default >>> - 6to4 SHOULD use a periodic reachability test to the relay similar = to what is specified in RFC5969 >=20 > Wouldn't these be reversed? If you mandate a reachability test to make = sure the 6to4 is valid, there's no problem with it enabled by default. I think not. I think enabling 6to4 should be a conscious decision. After = enabling 6to4 it should still be monitored to avoid problems at a later = time. So I think both suggestions are good. - Sander From Fred.L.Templin@boeing.com Thu Feb 3 07:59:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0BED3A697B for ; Thu, 3 Feb 2011 07:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XP0AQkvRxXq for ; Thu, 3 Feb 2011 07:59:04 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 5FA153A67F7 for ; Thu, 3 Feb 2011 07:59:04 -0800 (PST) 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 p13G2Aj8022824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Feb 2011 10:02:11 -0600 (CST) 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 p13G2AJW029695; Thu, 3 Feb 2011 08:02:10 -0800 (PST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p13G29fH029668 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 3 Feb 2011 08:02:09 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Thu, 3 Feb 2011 08:02:09 -0800 From: "Templin, Fred L" To: Brian E Carpenter , IPv6 Operations Date: Thu, 3 Feb 2011 08:02:08 -0800 Thread-Topic: [v6ops] [Fwd: I-DAction:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] Thread-Index: AcvDVHLlKwLn1KJoSASZMX95I5T4BgAZv7+Q Message-ID: References: <4D4A2401.2020500@gmail.com> In-Reply-To: <4D4A2401.2020500@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] [Fwd: I-DAction:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 15:59:05 -0000 Brian, > Two techniques for automatic tunneling of IPv6 over IPv4, intended > for situations where a user may wish to access IPv6-based services > via a network that does not support IPv6, were defined a number of > years ago. They are known as 6to4 [RFC3056], [RFC3068] and Teredo > [RFC4380]. For completion, shouldn't this also list ISATAP? Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Brian E Carpenter > Sent: Wednesday, February 02, 2011 7:42 PM > To: IPv6 Operations > Subject: [v6ops] [Fwd:=20 > I-DAction:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] >=20 > Hi, >=20 > This may be of interest. It's incomplete pending a co-author=20 > contribution > due soon, but there has been quite a bit of off-list discussion so > I though it was time to post the rough draft. >=20 > Brian >=20 > -------- Original Message -------- > Subject: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt > Date: Wed, 02 Feb 2011 19:30:01 -0800 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Advisory Guidelines for 6to4 and=20 > Teredo Deployment > Author(s) : B. Carpenter > Filename :=20 > draft-carpenter-v6ops-6to4-teredo-advisory-00.txt > Pages : 16 > Date : 2011-02-02 >=20 > This document provides advice to network operators about deployment > of two techniques for automatic tunneling of IPv6 over IPv4, namely > 6to4 and Teredo. It is principally addressed to Internet Service > Providers, including those that do not yet support IPv6, and to > Content Providers. The intention of the advice is to minimise both > user dissatisfaction and help desk calls. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-6to4 > -teredo-advisory-00.txt >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From ichiroumakino@gmail.com Thu Feb 3 08:03:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716FC3A69E5 for ; Thu, 3 Feb 2011 08:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK8thhAPNH9H for ; Thu, 3 Feb 2011 08:03:36 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 94E123A69E9 for ; Thu, 3 Feb 2011 08:03:35 -0800 (PST) Received: by eyd10 with SMTP id 10so776114eyd.31 for ; Thu, 03 Feb 2011 08:06:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=LgB095jztoNkS3gLurP9unfww+wA23UlNhIAd7vw+10=; b=lafQgE/+6I8xOO8SluxwHpwmPpeXcXh8N/DIDGEzQwrOrCwe+azqd8H9FkpoKtogul MUDSEyBPZcEik7+bvCcqJGiMNClRmOuf75763Kesq5TLPDirgpf3G9Tk30CDk1vFett7 lHV+dCWLt9jbtn27QIle5FFkp/SNgpz2xMngQ= 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=q0RMYDBKmCA64LAq7oQXtfb4l33wN66eVuyJeZ7WoCy+S4V36/QlRY5KRMU8v66cm1 o4INcIZPwshm2thurXY4+xMCImHNKdKy9o+bLRAbki1MRZvhXfObiQlf2hinUu6AveMd gZzo7FWFCd2r9AJQW9KkP5pc6GbCPEb0ZM6qA= Received: by 10.213.104.140 with SMTP id p12mr13683845ebo.76.1296749217252; Thu, 03 Feb 2011 08:06:57 -0800 (PST) Received: from gomlefisk.cisco.com (146.84-48-213.nextgentel.com [84.48.213.146]) by mx.google.com with ESMTPS id b52sm745346eei.13.2011.02.03.08.06.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 08:06:56 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Thu, 3 Feb 2011 17:06:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4A2401.2020500@gmail.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-DAction:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:03:39 -0000 Fred, >> Two techniques for automatic tunneling of IPv6 over IPv4, intended >> for situations where a user may wish to access IPv6-based services >> via a network that does not support IPv6, were defined a number of >> years ago. They are known as 6to4 [RFC3056], [RFC3068] and Teredo >> [RFC4380]. >=20 > For completion, shouldn't this also list ISATAP? you don't want to be with this crowd. ;-) seriously ISATAP is another class of tunnel, intra-site and managed = (even though that has lots of deployment issues too). the issue this draft addresses is how to deal with tunnels going across = the Internet, between if not non-consenting then unaware adults, = depending on the charity of unknown entities relaying packets for you... cheers, Ole= From jbates@brightok.net Thu Feb 3 08:04:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3BDC3A69A1 for ; Thu, 3 Feb 2011 08:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cL8sDVJi4S10 for ; Thu, 3 Feb 2011 08:04:57 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id D6F8E3A67F7 for ; Thu, 3 Feb 2011 08:04:56 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p13G8Irn018192; Thu, 3 Feb 2011 10:08:18 -0600 (CST) Message-ID: <4D4AD2F3.3020601@brightok.net> Date: Thu, 03 Feb 2011 10:08:19 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sander Steffann References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> In-Reply-To: <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:04:57 -0000 On 2/3/2011 9:54 AM, Sander Steffann wrote: > I think not. I think enabling 6to4 should be a conscious decision. > After enabling 6to4 it should still be monitored to avoid problems at > a later time. So I think both suggestions are good. > I think the problem is the advisory is pointed to ISPs, yet the enabled status of 6to4 is an end-host or CPE criteria. However, from a CPE or end-host criteria, 6to4 enabled by default should be fine, so long as it is monitored. In most policies, it is only used in 2 conditions 1) We received an AAAA 6to4 address, so we use 6to4 based on prefix (there should be no problems with this as long as the 6to4 network isn't behind NAT, which most systems properly detect this). 2) There was no A record, and 6to4 is the only available mechanism to reach the AAAA address. Most policies have to be changed for 6to4 to depend on anycast with the exception of #2, and if 6to4 is the only transport to reach the end node, it doesn't matter that we broke it. Jack From jhw@apple.com Thu Feb 3 08:12:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 082AE3A69FD for ; Thu, 3 Feb 2011 08:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.699 X-Spam-Level: X-Spam-Status: No, score=-103.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MANGLED_YOUR=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptVEkQJnWFsJ for ; Thu, 3 Feb 2011 08:12:10 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 4E9D83A69FE for ; Thu, 3 Feb 2011 08:12:10 -0800 (PST) Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out3.apple.com (Postfix) with ESMTP id 2A313CC6146C for ; Thu, 3 Feb 2011 08:15:33 -0800 (PST) X-AuditID: 11807135-b7cf8ae0000007ed-ff-4d4ad4a51827 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay12.apple.com (Apple SCV relay) with SMTP id 9F.5D.02029.5A4DA4D4; Thu, 3 Feb 2011 08:15:33 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [192.168.0.199] (wsip-70-167-79-234.sd.sd.cox.net [70.167.79.234]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LG100IVCUHSQB30@gertie.apple.com> for v6ops@ietf.org; Thu, 03 Feb 2011 08:15:32 -0800 (PST) From: james woodyatt In-reply-to: <4D46604E.30001@bogus.com> Date: Thu, 03 Feb 2011 08:15:28 -0800 Message-id: References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46604E.30001@bogus.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:12:11 -0000 On Jan 30, 2011, at 23:10, Joel Jaeggli wrote: > > The operative thing I took away from it is you can't just bridge > 802.15.4 to ethernet so if you want ot interconnect them you;r egoing to > have to route. Or use an application layer gateway. -- james woodyatt member of technical staff, communications engineering From joelja@bogus.com Thu Feb 3 08:13:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9FB3A6A10 for ; Thu, 3 Feb 2011 08:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.713 X-Spam-Level: X-Spam-Status: No, score=-100.713 tagged_above=-999 required=5 tests=[AWL=-1.614, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, MANGLED_YOUR=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENnVQ-V0ewzq for ; Thu, 3 Feb 2011 08:13:41 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id A051D3A6A0F for ; Thu, 3 Feb 2011 08:13:40 -0800 (PST) Received: from dhcp-176.nokia.net (dhcp-176.nokia.net [192.103.16.176] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p13GH0L5094326 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 3 Feb 2011 16:17:01 GMT (envelope-from joelja@bogus.com) Message-ID: <4D4AD4FC.5020802@bogus.com> Date: Thu, 03 Feb 2011 08:17:00 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: james woodyatt References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46604E.30001@bogus.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:13:41 -0000 On 2/3/11 8:15 AM, james woodyatt wrote: > On Jan 30, 2011, at 23:10, Joel Jaeggli wrote: >> >> The operative thing I took away from it is you can't just bridge >> 802.15.4 to ethernet so if you want ot interconnect them you;r egoing to >> have to route. > > Or use an application layer gateway. agree > > -- > james woodyatt > member of technical staff, communications engineering > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From moore@network-heretics.com Thu Feb 3 08:17:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5066E3A6A08 for ; Thu, 3 Feb 2011 08:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPSjQFHPDHzA for ; Thu, 3 Feb 2011 08:17:10 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id DC1123A69B4 for ; Thu, 3 Feb 2011 08:17:09 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 76090202D4; Thu, 3 Feb 2011 11:20:32 -0500 (EST) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 03 Feb 2011 11:20:32 -0500 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=XP0zFL2Kty1zJaYJdv0+f/HGaD0=; b=kSSWArFyEMeXzU7h+qfmqXtysWTJuMfzhTL//kSGAp3fGwkA5ONtyWlieUhJNZoeqJT2D+S2T3gFMuh/Kc7neIFT9qjxdhNy3z8H2c2Wr9Q6rtHuDfnTxQdpjK6avCGnu+YZLGVX6rWMU0D98E01wAy9v7yuE/OmpMP8Bx7q91Y= X-Sasl-enc: 3qmkO36jHqzaLbKW2zjdFrOiVrIqflTUIIntBHfPwquk 1296750032 Received: from 184-212-79-137.pools.spcsdns.net (184-212-79-137.pools.spcsdns.net [184.212.79.137]) by mail.messagingengine.com (Postfix) with ESMTPA id 3FEDA403DB8; Thu, 3 Feb 2011 11:20:31 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> Date: Thu, 3 Feb 2011 11:20:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 03 Feb 2011 08:21:02 -0800 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:17:11 -0000 On Feb 3, 2011, at 10:54 AM, Sander Steffann wrote: > Hi, >=20 >> On 2/3/2011 8:36 AM, Sander Steffann wrote: >>> - 6to4 MUST not be enabled by default >>>> - 6to4 SHOULD use a periodic reachability test to the relay similar = to what is specified in RFC5969 >>=20 >> Wouldn't these be reversed? If you mandate a reachability test to = make sure the 6to4 is valid, there's no problem with it enabled by = default. >=20 > I think not. I think enabling 6to4 should be a conscious decision. = After enabling 6to4 it should still be monitored to avoid problems at a = later time. So I think both suggestions are good. I don't see why enabling 6to4 should be any more of a conscious decision = than enabling IPv4. From Fred.L.Templin@boeing.com Thu Feb 3 08:22:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E54D3A699F for ; Thu, 3 Feb 2011 08:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTy5KSaKYuC5 for ; Thu, 3 Feb 2011 08:22:53 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id ED6753A69DA for ; Thu, 3 Feb 2011 08:22:49 -0800 (PST) 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 p13GQ7gc009639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Feb 2011 10:26:08 -0600 (CST) 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 p13GQ7Ob012844; Thu, 3 Feb 2011 10:26:07 -0600 (CST) 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 p13GQ7Zv012820 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 3 Feb 2011 10:26:07 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Thu, 3 Feb 2011 08:26:06 -0800 From: "Templin, Fred L" To: Ole Troan Date: Thu, 3 Feb 2011 08:26:05 -0800 Thread-Topic: [v6ops] [Fwd: I-DAction:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] Thread-Index: AcvDvL4dFGH6lHAtSaOTNWdmvS901QAAiy4g Message-ID: References: <4D4A2401.2020500@gmail.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: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-DAction:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:22:56 -0000 > > For completion, shouldn't this also list ISATAP? >=20 > you don't want to be with this crowd. ;-) Just checking... :^} Fred=20 > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of=20 > Ole Troan > Sent: Thursday, February 03, 2011 8:07 AM > To: Templin, Fred L > Cc: Brian E Carpenter; IPv6 Operations > Subject: Re: [v6ops] [Fwd:=20 > I-DAction:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] >=20 > Fred, >=20 > >> Two techniques for automatic tunneling of IPv6 over IPv4, intended > >> for situations where a user may wish to access IPv6-based services > >> via a network that does not support IPv6, were defined a number of > >> years ago. They are known as 6to4 [RFC3056], [RFC3068] and Teredo > >> [RFC4380]. > >=20 > > For completion, shouldn't this also list ISATAP? >=20 > you don't want to be with this crowd. ;-) >=20 > seriously ISATAP is another class of tunnel, intra-site and=20 > managed (even though that has lots of deployment issues too). >=20 > the issue this draft addresses is how to deal with tunnels=20 > going across the Internet, between if not non-consenting then=20 > unaware adults, depending on the charity of unknown entities=20 > relaying packets for you... >=20 > cheers, > Ole= From gert@space.net Thu Feb 3 08:32:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5CF3A69E4 for ; Thu, 3 Feb 2011 08:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CzbiUYAQYsj for ; Thu, 3 Feb 2011 08:32:43 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by core3.amsl.com (Postfix) with ESMTP id 7B1153A69B3 for ; Thu, 3 Feb 2011 08:32:42 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id EE775F8179 for ; Thu, 3 Feb 2011 17:36:03 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D6578F8111 for ; Thu, 3 Feb 2011 17:36:03 +0100 (CET) Received: (qmail 60478 invoked by uid 1007); 3 Feb 2011 17:36:03 +0100 Date: Thu, 3 Feb 2011 17:36:03 +0100 From: Gert Doering To: Keith Moore Message-ID: <20110203163603.GE44800@Space.Net> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:32:43 -0000 Hi, On Thu, Feb 03, 2011 at 11:20:29AM -0500, Keith Moore wrote: > I don't see why enabling 6to4 should be any more of a conscious decision than enabling IPv4. Because it does even more not work than IPv4. 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 jgammons@gmail.com Thu Feb 3 09:24:30 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C0B53A6A2B for ; Thu, 3 Feb 2011 09:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tru05vjEP34n for ; Thu, 3 Feb 2011 09:24:29 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 0574E3A686E for ; Thu, 3 Feb 2011 09:24:28 -0800 (PST) Received: by vxi40 with SMTP id 40so404162vxi.31 for ; Thu, 03 Feb 2011 09:27:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=gFX8tyzlF6Ed2oi7E9xPb9GwNDbPCwheZlwkZlSbs9s=; b=CDrqMHLFuk1kwmOACzIk1113o2Ns27DQeb6YiYBxHZ2INvalwA/w4AoJvl1uut72wc jjSF+MDOuzFPooR+M3EIfZKnq/cxrBrLgjJHjm7Rxrw+Xg+Vfm2eDHfKklEYyylE9guW bDqZBWgHsYSStM5Zdw09QLjy4U6arCqWZjLCw= 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=mTmdYwvYDwLg7d/WAitgr/AXOuxCLw/1MGRdNKW4zXHSAhfzeLor1KkxQguLE2/L9B wHc1XfXhjjaWtccTLaVWYLqkBWbfYgmnAZR/ntcILfXsBMFt8y+BQqlKrVi65BrF3fZ7 kLbreFNYC3TN2Jb1c8SbeH+DunmFqjcBvTIPI= Received: by 10.220.178.9 with SMTP id bk9mr2902780vcb.9.1296754071252; Thu, 03 Feb 2011 09:27:51 -0800 (PST) Received: from [10.64.32.36] (gw1.cox.com [24.248.74.254]) by mx.google.com with ESMTPS id a6sm417182vcm.46.2011.02.03.09.27.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 09:27:50 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: John Gammons In-Reply-To: <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> Date: Thu, 3 Feb 2011 12:27:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:24:30 -0000 On Feb 3, 2011, at 11:20 AM, Keith Moore wrote: > On Feb 3, 2011, at 10:54 AM, Sander Steffann wrote: >=20 >> Hi, >>=20 >>> On 2/3/2011 8:36 AM, Sander Steffann wrote: >>>> - 6to4 MUST not be enabled by default >>>>> - 6to4 SHOULD use a periodic reachability test to the relay = similar to what is specified in RFC5969 >>>=20 >>> Wouldn't these be reversed? If you mandate a reachability test to = make sure the 6to4 is valid, there's no problem with it enabled by = default. >>=20 >> I think not. I think enabling 6to4 should be a conscious decision. = After enabling 6to4 it should still be monitored to avoid problems at a = later time. So I think both suggestions are good. >=20 > I don't see why enabling 6to4 should be any more of a conscious = decision than enabling IPv4. Agreed. While I see both sides of this argument, from a CPE/Residential = Gateway perspective, I think IPv6 should be enabled by default. = Attempting native IPv6, and falling back to 6to4, before giving up = (surprisingly similar to the way Microsoft has handled this one). At = this stage of the game, some level of IPv6 connectivity is arguably a = requirement. While not perfect, I think the argument can be made that = problematic V6 connectivity, is better than none. =20 Expecting end-users to turn it on, only further escalates the = broken-ness. Given the complexity of the architecture and being able to = accurately weigh the benefits and disadvantages it provides, is = extremely difficult for the end-user, which will more often then not, = mean they "won't mess with that setting", shutting themselves out of V6 = land all together...=20 If it is enabled by default in the CPEs, then it will only further the = requirements of all operators and content providers to do their part to = ensure it's effectiveness, thereby making it less broken, which is the = fundamental purpose of this draft. =20 Excellent work on this draft btw, very useful to the community.... John > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Thu Feb 3 14:36:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B911B3A6B21 for ; Thu, 3 Feb 2011 14:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.181 X-Spam-Level: X-Spam-Status: No, score=-103.181 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hc8d2YEDilNs for ; Thu, 3 Feb 2011 14:36:55 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 849E33A6B16 for ; Thu, 3 Feb 2011 14:36:55 -0800 (PST) Received: by wwa36 with SMTP id 36so1807563wwa.13 for ; Thu, 03 Feb 2011 14:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=keQ3uHKtOQeg+qlFnZZJ26n0ljuxdl1UO6UjtcZv2GQ=; b=fh8aPvh3JiRI4mqmNBpUWPLifhblB9zrW0NRCSJmcIfo6ksYBC2fhq3x/rFSNztQE0 nNy6b8IrJuS+jVEtt6aEEpTQdqYizdaJOoIBeVVw8k7VveKl2+0doHh+stCrQDt0TSVj 2McArYa2iCekeVTf64QF60ptzOZ6XqgHyW1/0= 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=njG5dvmXqHkbiPCClBTftgyXaqkAWvrTpxyB6kCVBff0pKFeyJ7UlCB/jKnJCe2LwN h0yn/UKPQeE9zs+FT8783ZGGvKtX+rckZjb9qElxZMxUgKZmWvX5BoZW400xLI8ypXsN ktpCW1onmYRVjXh3jerVIlnolzvxrkAZnpgl8= Received: by 10.216.180.77 with SMTP id i55mr9915041wem.76.1296772816742; Thu, 03 Feb 2011 14:40:16 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id i80sm20371wej.4.2011.02.03.14.40.12 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 14:40:14 -0800 (PST) Message-ID: <4D4B2EC7.1010202@gmail.com> Date: Fri, 04 Feb 2011 11:40:07 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ole Troan References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> In-Reply-To: <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 22:36:56 -0000 On 2011-02-04 03:12, Ole Troan wrote: > Brian, > >> This may be of interest. It's incomplete pending a co-author contribution >> due soon, but there has been quite a bit of off-list discussion so >> I though it was time to post the rough draft. > > excellent draft and good recommendations. > > do you only want recommendations to operators or also to vendors? My thought was to focus this on operators, in the hope that they might actually read it, if we can push it out through the various operator forums ASAP. But of course I agree that there should be clear recommendations to stack implementers and vendors - that seems to need a bit of convergence on the 3484bis and happy-eyeballs discussions, though. How about a separate draft? Brian > e.g. I would have liked: > > - 6to4 MUST not be enabled by default > - 6to4 SHOULD use a periodic reachability test to the relay similar to what is specified in RFC5969 > - 6to4/Teredo MUST by default be at the least preferred option in SAS/DAS selection policy. i.e. prefer NATed IPv4 over 6to4/Teredo > > - for networks that want to stop 6to4/Teredo traffic. a captive portal could be used to make users aware that they are using Teredo/6to4 and be given instructions for how to turn it off. > > cheers, > Ole > >> -------- Original Message -------- >> Subject: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt >> Date: Wed, 02 Feb 2011 19:30:01 -0800 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : Advisory Guidelines for 6to4 and Teredo Deployment >> Author(s) : B. Carpenter >> Filename : draft-carpenter-v6ops-6to4-teredo-advisory-00.txt >> Pages : 16 >> Date : 2011-02-02 >> >> This document provides advice to network operators about deployment >> of two techniques for automatic tunneling of IPv6 over IPv4, namely >> 6to4 and Teredo. It is principally addressed to Internet Service >> Providers, including those that do not yet support IPv6, and to >> Content Providers. 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-carpenter-v6ops-6to4-teredo-advisory-00.txt >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From dr@cluenet.de Thu Feb 3 14:40:30 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94B573A6B28 for ; Thu, 3 Feb 2011 14:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Oq4n-6L08TY for ; Thu, 3 Feb 2011 14:40:29 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 67AE03A687A for ; Thu, 3 Feb 2011 14:40:29 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id D51D91080EF; Thu, 3 Feb 2011 23:43:51 +0100 (CET) Date: Thu, 3 Feb 2011 23:43:51 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110203224351.GA27225@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 22:40:30 -0000 Hi, while discussing using IPv6 MTU >1500 in DS-Lite context on DOCSIS access networks (to avoid fragmentation), we stumbled across the following in RFC2464 (IPv6 over Ethernet): --------------------------------------------------------------------- 2. Maximum Transmission Unit The default MTU size for IPv6 [IPV6] packets on an Ethernet is 1500 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of each node. If a Router Advertisement received on an Ethernet interface has an MTU option specifying an MTU larger than 1500, or larger than a manually configured value, that MTU option may be logged to system management but must be otherwise ignored. For purposes of this document, information received from DHCP is considered "manually configured" and the term Ethernet includes CSMA/CD and full-duplex subnetworks based on ISO/IEC 8802-3, with various data rates. --------------------------------------------------------------------- Source: http://tools.ietf.org/html/rfc2464 The IPv6 DOCSIS scenario calls for RAs from the CMTS, without advertised prefix, with M=1 to enforce stateful DHCPv6 by customers to obtain IPv6 address/prefix delegation. As far as I read the text above, CPE routers connected to a CMTS advertising MTU >1500 in the RAs are supposed to ignored that value and fall back to 1500. Is that understanding correct? If so, what's the underlying reason for that? A router advertising itself on a link can't be trusted to know that a link has a higher than default MTU!? Or is it about making sure there won't be SLAAC on >1500 MTU links in order to cater for non-"jumbo" capable hosts? Given that we enforce DHCPv6 anyway, we might advertise a higher MTU in DHCPv6 replies. As I understand the RFC, that would be considered "manual configuration" and legit. Does anyone see potential operational problem with such a "two-stage", inconsistent MTU advertisement (first via RA, then ultimately via DHCPv6 with higher MTU)? Given that there is no SLAAC happening, that _should_ be safe, as any new endpoint coming alive will do DHCPv6 and is supposed to actually use the MTU value received there, correct? What is supposed to happen when a CPE device is being connected not supporting MTU >1500 but receiving such MTU in DHCPv6 reply? My guess is, that the interface shouldn't/wouldn't come operational. Any suggested reading appreciated. Any suggestions for approaches to selectively use higher than 1500 octet MTU to some endpoints (specifically DS-Lite B4s) also very welcome. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From dr@cluenet.de Thu Feb 3 14:45:07 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1670C3A6B39 for ; Thu, 3 Feb 2011 14:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psoppDoNdBZD for ; Thu, 3 Feb 2011 14:45:06 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 218863A6B33 for ; Thu, 3 Feb 2011 14:45:06 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 16BA2108104; Thu, 3 Feb 2011 23:48:29 +0100 (CET) Date: Thu, 3 Feb 2011 23:48:29 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110203224829.GB27225@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <4D4B2EC7.1010202@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D4B2EC7.1010202@gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 22:45:07 -0000 Hi, On Fri, Feb 04, 2011 at 11:40:07AM +1300, Brian E Carpenter wrote: > My thought was to focus this on operators, in the hope that they > might actually read it, if we can push it out through the various > operator forums ASAP. I haven't had time to toroughly review it, but crossreading it, it is a very useful document on many (all?) the gotchas involved. Thanks from an operator. :-) > But of course I agree that there should be clear recommendations > to stack implementers and vendors Agreed. And we operators need such stuff _quickly_ to have references to point CPE vendors to how to un-suck their implementations properly, quickly. > > e.g. I would have liked: > > > > - 6to4 MUST not be enabled by default > > - 6to4 SHOULD use a periodic reachability test to the relay similar to what is specified in RFC5969 > > - 6to4/Teredo MUST by default be at the least preferred option in SAS/DAS selection policy. i.e. prefer NATed IPv4 over 6to4/Teredo Agreed on all of those. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From dr@cluenet.de Thu Feb 3 15:01:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D44A3A6B37 for ; Thu, 3 Feb 2011 15:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T59cgaGzTrVn for ; Thu, 3 Feb 2011 15:01:49 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 3F5BB3A6B39 for ; Thu, 3 Feb 2011 15:01:49 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 32666108123; Fri, 4 Feb 2011 00:05:12 +0100 (CET) Date: Fri, 4 Feb 2011 00:05:12 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110203230512.GA32291@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> <913371.73213.qm@web111411.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 23:01:50 -0000 On Tue, Jan 11, 2011 at 03:11:38AM +0000, Erik Kline wrote: > +1 to marking IPv4 historic, if it hasn't been already +1 Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From jhw@apple.com Thu Feb 3 16:00:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410EB3A6B50 for ; Thu, 3 Feb 2011 16:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2L-avodjYv0Y for ; Thu, 3 Feb 2011 16:00:24 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 86C393A6B4C for ; Thu, 3 Feb 2011 16:00:24 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 08043CFF6DF7 for ; Thu, 3 Feb 2011 16:03:48 -0800 (PST) X-AuditID: 11807134-b7c40ae000006cb9-fe-4d4b4263d79f Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with SMTP id 2D.21.27833.3624B4D4; Thu, 3 Feb 2011 16:03:47 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.153.99.160] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LG200IFCG6ALE10@elliott.apple.com> for v6ops@ietf.org; Thu, 03 Feb 2011 16:03:47 -0800 (PST) From: james woodyatt In-reply-to: <20110203224351.GA27225@srv03.cluenet.de> Date: Thu, 03 Feb 2011 16:03:46 -0800 Message-id: <4EBD8897-DAA1-4E18-8234-7BCBAE1D9EB8@apple.com> References: <20110203224351.GA27225@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 00:00:25 -0000 On Feb 3, 2011, at 14:43, Daniel Roesen wrote: > > [...] A router advertising itself on a link can't be trusted to know that a link has a higher than default MTU!? [...] I would suggest that is a document worth reviewing for insight into the relevant issues here. -- james woodyatt member of technical staff, communications engineering From volz@cisco.com Thu Feb 3 19:00:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058353A69FF for ; Thu, 3 Feb 2011 19:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.556 X-Spam-Level: X-Spam-Status: No, score=-9.556 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coU-5V-UI2vl for ; Thu, 3 Feb 2011 19:00:10 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D41263A6A12 for ; Thu, 3 Feb 2011 19:00:09 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApABALv6Sk2tJV2a/2dsb2JhbACWU45lc6FFmwSFWASEeYof Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 04 Feb 2011 03:03:33 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1433Xj2026017; Fri, 4 Feb 2011 03:03:33 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 21:03:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Feb 2011 21:03:31 -0600 Message-ID: In-Reply-To: <20110203224351.GA27225@srv03.cluenet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvD8953ArqM1LbdSNasQ9C+o3GUGAAI2JQQ References: <20110203224351.GA27225@srv03.cluenet.de> From: "Bernie Volz (volz)" To: "Daniel Roesen" , X-OriginalArrivalTime: 04 Feb 2011 03:03:32.0751 (UTC) FILETIME=[1B5CB1F0:01CBC418] Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 03:00:13 -0000 Just as an FYI - there is no MTU "option" in DHCPv6 ... so, I'm not sure what you're talking about when saying "we might advertise a higher MTU in DHCPv6 replies" and "we might advertise a higher MTU in DHCPv6 replies". Perhaps there's a draft I've missed regarding an MTU option for DHCPv6?=20 http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtm l - Bernie -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Daniel Roesen Sent: Thursday, February 03, 2011 5:44 PM To: v6ops@ietf.org Subject: [v6ops] RFC 2464 - MTU >1500 Hi, while discussing using IPv6 MTU >1500 in DS-Lite context on DOCSIS access networks (to avoid fragmentation), we stumbled across the following in RFC2464 (IPv6 over Ethernet): --------------------------------------------------------------------- 2. Maximum Transmission Unit The default MTU size for IPv6 [IPV6] packets on an Ethernet is 1500 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of each node. If a Router Advertisement received on an Ethernet interface has an MTU option specifying an MTU larger than 1500, or larger than a manually configured value, that MTU option may be logged to system management but must be otherwise ignored. For purposes of this document, information received from DHCP is considered "manually configured" and the term Ethernet includes CSMA/CD and full-duplex subnetworks based on ISO/IEC 8802-3, with various data rates. --------------------------------------------------------------------- Source: http://tools.ietf.org/html/rfc2464 The IPv6 DOCSIS scenario calls for RAs from the CMTS, without advertised prefix, with M=3D1 to enforce stateful DHCPv6 by customers to obtain IPv6 address/prefix delegation. As far as I read the text above, CPE routers connected to a CMTS advertising MTU >1500 in the RAs are supposed to ignored that value and fall back to 1500. Is that understanding correct? If so, what's the underlying reason for that? A router advertising itself on a link can't be trusted to know that a link has a higher than default MTU!? Or is it about making sure there won't be SLAAC on >1500 MTU links in order to cater for non-"jumbo" capable hosts? Given that we enforce DHCPv6 anyway, we might advertise a higher MTU in DHCPv6 replies. As I understand the RFC, that would be considered "manual configuration" and legit. Does anyone see potential operational problem with such a "two-stage", inconsistent MTU advertisement (first via RA, then ultimately via DHCPv6 with higher MTU)? Given that there is no SLAAC happening, that _should_ be safe, as any new endpoint coming alive will do DHCPv6 and is supposed to actually use the MTU value received there, correct? What is supposed to happen when a CPE device is being connected not supporting MTU >1500 but receiving such MTU in DHCPv6 reply? My guess is, that the interface shouldn't/wouldn't come operational. Any suggested reading appreciated. Any suggestions for approaches to selectively use higher than 1500 octet MTU to some endpoints (specifically DS-Lite B4s) also very welcome. :-) Best regards, Daniel --=20 CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From victor.kuarsingh@gmail.com Thu Feb 3 20:34:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB4AA3A69CA for ; Thu, 3 Feb 2011 20:34:43 -0800 (PST) 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.500, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWFHGduTfiwA for ; Thu, 3 Feb 2011 20:34:42 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 9DFBD3A67D6 for ; Thu, 3 Feb 2011 20:34:42 -0800 (PST) Received: by yxt33 with SMTP id 33so883233yxt.31 for ; Thu, 03 Feb 2011 20:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=xz/FrvijaeMzR54bwzw5LqlAgBzIP8wOyH8C3NYOd7k=; b=i0jHMYH8hcJ9aoqwF8toqNsyFfOOd7j+RN+0cKrTMUcCKUPd/Bh297onMLyvLJTHCa TlKjAYHL3U/SFkIvoW1nuAjObwuqjlrqeIvCZu5rleFtkj1YeCbMfUJsXyastuRizQja jwNTeb7WFhGpvYKjiqZ+Ru/EnPiGx+UlBkfaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; b=DdRGYnNkTqJRAwsP5Pmiuqq/zng3eE+bWH4PkmWYnzkNdmldqoMsCpEIWBP213CcNX hrPM27xrOACmRZ+ehTdS2QKDY7ofl5xUObbuLgYvR3laBCs0yxkdJigW8+LryaLP7TEN kg0mHicwVV0GrZLTcGlSlOmcI9D2y/p50XcRQ= Received: by 10.236.110.2 with SMTP id t2mr17007161yhg.34.1296794285807; Thu, 03 Feb 2011 20:38:05 -0800 (PST) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id j3sm220052yha.7.2011.02.03.20.38.03 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 20:38:04 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 03 Feb 2011 23:43:50 -0500 From: Victor Kuarsingh To: John Gammons , Keith Moore Message-ID: Thread-Topic: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 04:34:43 -0000 On 03/02/11 12:27 PM, "John Gammons" wrote: > >On Feb 3, 2011, at 11:20 AM, Keith Moore wrote: > >> On Feb 3, 2011, at 10:54 AM, Sander Steffann wrote: >> >>> Hi, >>> >>>> On 2/3/2011 8:36 AM, Sander Steffann wrote: >>>>> - 6to4 MUST not be enabled by default >>>>>> - 6to4 SHOULD use a periodic reachability test to the relay similar >>>>>>to what is specified in RFC5969 >>>> >>>> Wouldn't these be reversed? If you mandate a reachability test to >>>>make sure the 6to4 is valid, there's no problem with it enabled by >>>>default. >>> >>> I think not. I think enabling 6to4 should be a conscious decision. >>>After enabling 6to4 it should still be monitored to avoid problems at a >>>later time. So I think both suggestions are good. >> >> I don't see why enabling 6to4 should be any more of a conscious >>decision than enabling IPv4. > >Agreed. While I see both sides of this argument, from a CPE/Residential >Gateway perspective, I think IPv6 should be enabled by default. >Attempting native IPv6, and falling back to 6to4, before giving up >(surprisingly similar to the way Microsoft has handled this one). At >this stage of the game, some level of IPv6 connectivity is arguably a >requirement. While not perfect, I think the argument can be made that >problematic V6 connectivity, is better than none. > >Expecting end-users to turn it on, only further escalates the >broken-ness. Given the complexity of the architecture and being able to >accurately weigh the benefits and disadvantages it provides, is extremely >difficult for the end-user, which will more often then not, mean they >"won't mess with that setting", shutting themselves out of V6 land all >together... > >If it is enabled by default in the CPEs, then it will only further the >requirements of all operators and content providers to do their part to >ensure it's effectiveness, thereby making it less broken, which is the >fundamental purpose of this draft. > >Excellent work on this draft btw, very useful to the community.... I would agree with John. Expecting users to turn anything on (at mass) is like not having it at all. Most of my customers use default everything. The suggestion of attempting Native IPv6 followed by 6to4 (perhaps you can put in 6RD ahead of this if it is possible in a specific network) is a reasonable approach. No IPv6 in this new world is not better some IPv6 (some may argue the performance is bad a times). If the address selection works correctly, then the customer will at least be able to get to an IPv6 endpoint if required. As for our network, 6to4 works reasonably well. In our characterization and lab work, 6to4 is the least of our concerns. It's the Native IPv6 code in CPEs that is causing us most of the issues. >From an operator standpoint I think the following makes perfect sense: - Try Native IPv6 - if that fails, managed tunnel - if that fails 6to4 (anycast) - if that fails IPv4 only Regards, Victor K > >John > >> _______________________________________________ >> 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 ek@google.com Fri Feb 4 00:47:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3CC63A6890 for ; Fri, 4 Feb 2011 00:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.912 X-Spam-Level: X-Spam-Status: No, score=-105.912 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Owbm3w-YStrI for ; Fri, 4 Feb 2011 00:47:21 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id EC39C3A688B for ; Fri, 4 Feb 2011 00:47:20 -0800 (PST) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p148oixm028173 for ; Fri, 4 Feb 2011 00:50:44 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296809444; bh=g6SxnQEpJR0rG58NYu5RJd5eWFo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=f7fDrFGMAunodCSVh2Pp0Ud2w2VyTNPg37BvFY3c+pNc1EhI8Od8IATHdkvCpteuU qeWL/AEvCqT6aGqytX1Jg== Received: from qwk4 (qwk4.prod.google.com [10.241.195.132]) by hpaq11.eem.corp.google.com with ESMTP id p148oOSW017702 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 4 Feb 2011 00:50:43 -0800 Received: by qwk4 with SMTP id 4so1642424qwk.18 for ; Fri, 04 Feb 2011 00:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=TcLi5PjQf1/h/chOei6YGK8ORubmoscr0NvhQFbsYlo=; b=ahQPSLnso1V/k1v3pWnczVxMjP9CQtdkhhaZ2fcWwV77XkzR3HSZLfhpGc+xN2KN/w ke9fgMwsbguqFpPJ6inA== 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 :content-type; b=Ici3zFfnvWdZBcW7Jg/ORTIMlUo514nQa5Pkcp750iGzZHfNt1HIYdc9u76UJzxTOV g3nVNbaK93+sCVoWAgGg== MIME-Version: 1.0 Received: by 10.229.192.70 with SMTP id dp6mr1511564qcb.219.1296809442715; Fri, 04 Feb 2011 00:50:42 -0800 (PST) Received: by 10.229.111.210 with HTTP; Fri, 4 Feb 2011 00:50:42 -0800 (PST) In-Reply-To: <20110203224351.GA27225@srv03.cluenet.de> References: <20110203224351.GA27225@srv03.cluenet.de> Date: Fri, 4 Feb 2011 17:50:42 +0900 Message-ID: From: Erik Kline To: v6ops@ietf.org Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 08:47:21 -0000 I thought that if there were no MTU option in the RA the node is responsible for figuring out the MTU of the link. It would seem to me that you just need to /not/ send an MTU option? Maybe I'm confused though. From narten@us.ibm.com Fri Feb 4 05:39:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD4393A6916 for ; Fri, 4 Feb 2011 05:39:28 -0800 (PST) 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.462, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IejeE0D1LXsr for ; Fri, 4 Feb 2011 05:39:28 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 0889E3A6911 for ; Fri, 4 Feb 2011 05:39:27 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p14DHa6E010573 for ; Fri, 4 Feb 2011 08:17:54 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 6D7554DE8026 for ; Fri, 4 Feb 2011 08:42:13 -0500 (EST) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p14DgqWi193240 for ; Fri, 4 Feb 2011 08:42:52 -0500 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p14Dgpdk016472 for ; Fri, 4 Feb 2011 06:42:51 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-206-115.mts.ibm.com [9.65.206.115]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p14Dgo3g016435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Feb 2011 06:42:51 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p14DgnOV017566; Fri, 4 Feb 2011 08:42:50 -0500 Message-Id: <201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com> To: Erik Kline In-reply-to: References: <20110203224351.GA27225@srv03.cluenet.de> Comments: In-reply-to Erik Kline message dated "Fri, 04 Feb 2011 17:50:42 +0900." Date: Fri, 04 Feb 2011 08:42:49 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 13:39:29 -0000 Erik Kline writes: > I thought that if there were no MTU option in the RA the node is > responsible for figuring out the MTU of the link. I would word that slightly differently. Every link type has a default MTU. The IPoverFoo document for a particular link type defines the value. The MTU option in an RA can be used to override the default, in cases where the default value is somehow not optimal. Thomas From jbates@brightok.net Fri Feb 4 06:51:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263823A6949 for ; Fri, 4 Feb 2011 06:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.717 X-Spam-Level: X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZyMotp1nW6U for ; Fri, 4 Feb 2011 06:51:19 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 231783A696A for ; Fri, 4 Feb 2011 06:51:18 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p14EsgrL018951; Fri, 4 Feb 2011 08:54:42 -0600 (CST) Message-ID: <4D4C1332.1050408@brightok.net> Date: Fri, 04 Feb 2011 08:54:42 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Victor Kuarsingh References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 14:51:20 -0000 On 2/3/2011 10:43 PM, Victor Kuarsingh wrote: > - Try Native IPv6 This is provisioning. If we get it on connection, a standard policy should allow this anytime an AAAA is present, even when an A exists. > - if that fails, managed tunnel This follows with above. I presume the managed tunnel is something special a provider did for their own CPEs. > - if that fails 6to4 (anycast) If 6to4 is active, standard policy (at least in windows world, and it works well) 1) If we have RFC-1918, 6to4 is deactivated, as it won't work through NAT. This will still be a concern with an ISP due to CGN, though there are cases where provider side may not be RFC-1918 and this may be an issue. I would hope that a provider deploying CGN has other mechanisms so that 6to4 isn't used. This is mitigated by below (ie, only 2 will break where IPv4 would succeed and most content publishers don't use 6to4 AAAA addresses) 2) 6to4 -> 6to4 goes direct when AAAA is present, even with an A exists 3) 6to4 -> anycast is used ONLY when an A record doesn't exist. > - if that fails IPv4 only 6to4 generally won't have an IPv4 backup, though the others will. Jack From remi.despres@free.fr Fri Feb 4 08:09:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F351A3A69BF for ; Fri, 4 Feb 2011 08:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7UAE7w1k+pN for ; Fri, 4 Feb 2011 08:09:19 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by core3.amsl.com (Postfix) with ESMTP id EAD293A67F7 for ; Fri, 4 Feb 2011 08:09:18 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id 9E52B700009A; Fri, 4 Feb 2011 17:12:43 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id A935B7000096; Fri, 4 Feb 2011 17:12:40 +0100 (CET) X-SFR-UUID: 20110204161240693.A935B7000096@msfrf2118.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 4 Feb 2011 17:12:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> To: John Gammons X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 16:09:20 -0000 Le 3 f=E9vr. 2011 =E0 18:27, John Gammons a =E9crit : > On Feb 3, 2011, at 11:20 AM, Keith Moore wrote: >=20 >> On Feb 3, 2011, at 10:54 AM, Sander Steffann wrote: >>>=20 >>> ... I think enabling 6to4 should be a conscious decision. +1 >>> After enabling 6to4 it should still be monitored to avoid problems = at a later time. So I think both suggestions are good. >>=20 >> I don't see why enabling 6to4 should be any more of a conscious = decision than enabling IPv4. (I assume Keith meant enabling "IPv6".) In my understanding, reasons to limit default IPv6 enablement to native = IPv6 addresses (and exclude in it 6to4 addresses) are precisely what = this draft-carpenter explains: - Connections from a 6to4 address to a native IPv6 address may fail, and = DO FAIL in a number of configurations where there is no return path. - Connections from a native IPv6 address to another native IPv6 address = don't have the same intrinsic problem. (And this applies including to = IPv6 addresses obtained across configured or 6rd tunnels). =20 Thus, as long as there are hosts that don't handle 6to4 addresses = differently from native IPv6 addresses, CPEs should better avoid = enabling 6to4 by default, and should at least make it easy to disable = it. =20 > Agreed. While I see both sides of this argument, from a = CPE/Residential Gateway perspective, I think IPv6 should be enabled by = default. Attempting native IPv6, and falling back to 6to4, before = giving up (surprisingly similar to the way Microsoft has handled this = one). At this stage of the game, some level of IPv6 connectivity is = arguably a requirement. While not perfect, I think the argument can be = made that problematic V6 connectivity, is better than none. Quite different view here: - Problematic IPv6 leads to bad user experience, and leads to IPv6 being = completely turned off. - No such problem exists with good quality IPv6 (one that provides = additional connectivity to users that need it, and that never replaces a = working IPv4 connectivity by a failing on in IPv6.=20 Happy eyeballs is an approach to mitigate consequences of failing IPv6 = connectivity, but its support in all hosts shouldn't be assumed to be = available for quite some time. =20 > Expecting end-users to turn it on, only further escalates the = broken-ness. Given the complexity of the architecture and being able to = accurately weigh the benefits and disadvantages it provides, is = extremely difficult for the end-user, which will more often then not, = mean they "won't mess with that setting", shutting themselves out of V6 = land all together...=20 >=20 > If it is enabled by default in the CPEs, then it will only further the = requirements of all operators and content providers to do their part to = ensure it's effectiveness, thereby making it less broken, which is the = fundamental purpose of this draft. > Excellent work on this draft btw, very useful to the community.... Agreed. Regards, RD From jbates@brightok.net Fri Feb 4 08:48:35 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E7A3A69AF for ; Fri, 4 Feb 2011 08:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxWsSDYsvqNR for ; Fri, 4 Feb 2011 08:48:34 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 106883A69CD for ; Fri, 4 Feb 2011 08:48:33 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p14Gpuj2012069; Fri, 4 Feb 2011 10:51:56 -0600 (CST) Message-ID: <4D4C2EAC.2030509@brightok.net> Date: Fri, 04 Feb 2011 10:51:56 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 16:48:35 -0000 On 2/4/2011 10:12 AM, Rémi Després wrote: > In my understanding, reasons to limit default IPv6 enablement to > native IPv6 addresses (and exclude in it 6to4 addresses) are > precisely what this draft-carpenter explains: - Connections from a > 6to4 address to a native IPv6 address may fail, and DO FAIL in a > number of configurations where there is no return path. - Connections > from a native IPv6 address to another native IPv6 address don't have > the same intrinsic problem. (And this applies including to IPv6 > addresses obtained across configured or 6rd tunnels). > If there is no native IPv6, 6to4 would need to be enabled (which users won't do manually) to get any connectivity to IPv6. Default windows policy (and should be default for all 6to4) is that the ONLY time 6to4 over-rides IPv4 is to reach another 6to4 address (advertised in an AAAA). IPv4 has precedence over using 6to4 in all other cases (unless the policy is manually changed). However, having 6to4 enabled does allow the device to reach an IPv6 only host. > Thus, as long as there are hosts that don't handle 6to4 addresses > differently from native IPv6 addresses, CPEs should better avoid > enabling 6to4 by default, and should at least make it easy to disable > it. > They should always be handled differently. That is what should be fixed if it is broken. Jack From remi.despres@free.fr Fri Feb 4 09:37:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A6C3A69F5 for ; Fri, 4 Feb 2011 09:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCY4wgZrFQ4q for ; Fri, 4 Feb 2011 09:37:32 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by core3.amsl.com (Postfix) with ESMTP id 398123A69E3 for ; Fri, 4 Feb 2011 09:37:32 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id 9AA0E700008E; Fri, 4 Feb 2011 18:40:56 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id EC756700009C; Fri, 4 Feb 2011 18:40:55 +0100 (CET) X-SFR-UUID: 20110204174055968.EC756700009C@msfrf2214.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D4C2EAC.2030509@brightok.net> Date: Fri, 4 Feb 2011 18:40:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 17:37:33 -0000 Le 4 f=E9vr. 2011 =E0 17:51, Jack Bates a =E9crit : > On 2/4/2011 10:12 AM, R=E9mi Despr=E9s wrote: >> In my understanding, reasons to limit default IPv6 enablement to >> native IPv6 addresses (and exclude in it 6to4 addresses) are >> precisely what this draft-carpenter explains: - Connections from a >> 6to4 address to a native IPv6 address may fail, and DO FAIL in a >> number of configurations where there is no return path. - Connections >> from a native IPv6 address to another native IPv6 address don't have >> the same intrinsic problem. (And this applies including to IPv6 >> addresses obtained across configured or 6rd tunnels). >>=20 >=20 > If there is no native IPv6, 6to4 would need to be enabled (which users = won't do manually) to get any connectivity to IPv6. >=20 > Default windows policy (and should be default for all 6to4) is that = the ONLY time 6to4 over-rides IPv4 is to reach another 6to4 address = (advertised in an AAAA). IPv4 has precedence over using 6to4 in all = other cases (unless the policy is manually changed). I agree that this is the right policy because it makes sure 6to4 relays = are never used where IPv4 remains available. (Today, IPv4 generally remains available, be it with NATs and = hole-punching technologies for incoming connectivities.) > However, having 6to4 enabled does allow the device to reach an IPv6 = only host. Some IPv6-only hosts, yes, but not all those that have native IPv6 = addresses without having also IPv6 addresses. That's where the brokenness comes, and IMHO should be avoided. I don't know how many servers are accessible ONLY in IPv6, and ONLY at = native IPv6 addresses (i.e. without having also 6to4 addresses). But this is a configuration I wouldn't recommend for any server that has = to be reachable also from 6to4 addresses. >> Thus, as long as there are hosts that don't handle 6to4 addresses >> differently from native IPv6 addresses, CPEs should better avoid >> enabling 6to4 by default, and should at least make it easy to disable >> it. >>=20 >=20 > They should always be handled differently. That is what should be = fixed if it is broken. Yes. Until it is fixed, though, it remains safer that CPEs activate IPv6 by = default only if their IPv6 prefixes are native (natively routed or with = 6rd). Regards, RD =20 From remi.despres@free.fr Fri Feb 4 09:38:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DFBA3A68C5 for ; Fri, 4 Feb 2011 09:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohnnH5I3E4p1 for ; Fri, 4 Feb 2011 09:38:02 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by core3.amsl.com (Postfix) with ESMTP id 565643A69E3 for ; Fri, 4 Feb 2011 09:38:02 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id 7057E7000095; Fri, 4 Feb 2011 18:41:27 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id 34988700009E; Fri, 4 Feb 2011 18:41:27 +0100 (CET) X-SFR-UUID: 20110204174127215.34988700009E@msfrf2214.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> Date: Fri, 4 Feb 2011 18:41:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9C592141-D8AE-4057-9A0A-C1111885349F@free.fr> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 17:38:03 -0000 Le 4 f=E9vr. 2011 =E0 17:20, Keith Moore a =E9crit : >=20 > On Feb 4, 2011, at 11:12 AM, R=E9mi Despr=E9s wrote: >>=20 >>> On Feb 3, 2011, at 11:20 AM, Keith Moore wrote: >>>> ...I don't see why enabling 6to4 should be any more of a conscious = decision than enabling IPv4. >>=20 >> (I assume Keith meant enabling "IPv6".) >=20 > No, actually I meant enabling 6to4. 6to4 ... more ... than ... IPv4? (as you wrote) OR 6=20 6to4 ... more ... than ... IPv6? (as I interpreted) > IMO, 6to4 should be enabled by default on every host that has IPv4 = connectivity and public address space. =20 >=20 > However I'm all for hosts having heuristics that avoid using 6to4 = source addresses to contact non-6to4 addresses if the anycast relay (or = other relay router) or return path is nonexistent or broken. The point is that, as long as these "heuristics" aren't generalized, = 6to4 causes diverse IPv6 brokenness that are detrimental to IPv6 in = general. Regards, RD From jbates@brightok.net Fri Feb 4 09:55:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15F93A69AF for ; Fri, 4 Feb 2011 09:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHsqSsVaWDPo for ; Fri, 4 Feb 2011 09:55:21 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 2C9903A694A for ; Fri, 4 Feb 2011 09:55:21 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p14HwfF7000292; Fri, 4 Feb 2011 11:58:41 -0600 (CST) Message-ID: <4D4C3E51.8070503@brightok.net> Date: Fri, 04 Feb 2011 11:58:41 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> In-Reply-To: <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 17:55:24 -0000 On 2/4/2011 11:40 AM, Rémi Després wrote: >> However, having 6to4 enabled does allow the device to reach an IPv6 >> only host. > > Some IPv6-only hosts, yes, but not all those that have native IPv6 > addresses without having also IPv6 addresses. That's where the > brokenness comes, and IMHO should be avoided. > > I don't know how many servers are accessible ONLY in IPv6, and ONLY > at native IPv6 addresses (i.e. without having also 6to4 addresses). > But this is a configuration I wouldn't recommend for any server that > has to be reachable also from 6to4 addresses. > If it's IPv6 only, it won't have a 6to4 address (otherwise it could be reachable via IPv4). It is HIGHLY recommended that no content sites should advertise 6to4 addressing. That said, it is highly recommended that an IPv4 content site support 6to4 that isn't advertised. The reason is that if a host uses 6to4 anycast to reach a native address (overriding the proper policy), the server can actually reply directly through the 6to4 interface. >> They should always be handled differently. That is what should be >> fixed if it is broken. > > Yes. Until it is fixed, though, it remains safer that CPEs activate > IPv6 by default only if their IPv6 prefixes are native (natively > routed or with 6rd). Except that this will break all IPv6 connectivity. If they can change the code to be disabled, they should be able to change it to just operate with the appropriate policy. I agree that it is better to deactivate the 6to4 *IF* a CPE isn't going to use a policy. Jack From moore@network-heretics.com Thu Feb 3 09:29:52 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B4A3A6A3C for ; Thu, 3 Feb 2011 09:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dcNQ4n1fB8b for ; Thu, 3 Feb 2011 09:29:50 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id 7D22B3A6A3A for ; Thu, 3 Feb 2011 09:29:50 -0800 (PST) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 2ADE920975; Thu, 3 Feb 2011 12:33:13 -0500 (EST) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 03 Feb 2011 12:33:13 -0500 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=VlkcZfAejtw9e4EldU9p3I1N6+Y=; b=pZeaP1IEHEBD30p/78Lr34inU/kr83LH2pWNRWiUyOakVnKkIIIIU5pgpGqXb2AvtltaQqX7aU/9RxJEXYx1gAqtorMNNmxrByVgGkspq0YiVDtljPYRHcYnrnFDz4f3/1SHM3Ud+JFC9F9ECC53C6B/vEboVW09wYgWtYP9KEg= X-Sasl-enc: gnjqS3Ohz3kAk0np4WfYX0r8mFj/G+k963ItkOy7Oj03 1296754391 Received: from 184-212-79-137.pools.spcsdns.net (184-212-79-137.pools.spcsdns.net [184.212.79.137]) by mail.messagingengine.com (Postfix) with ESMTPA id DA51540BB7D; Thu, 3 Feb 2011 12:33:07 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Thu, 3 Feb 2011 12:33:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <27F3F95D-3D43-48BF-8B15-40FD5763B040@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> To: John Gammons X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Fri, 04 Feb 2011 10:02:37 -0800 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:29:52 -0000 I suppose I should add that having a host prefer either native v6 or = 6to4 over native v4 should probably be dependent on reachability. If = there's no v6 routing to external networks, or no effective 6to4 relay = router, and there is routing to public v4 then the host should probably = prefer v4 to a nonlocal v6 address. But that's not the same thing as = disabling v6 or 6to4. Keith On Feb 3, 2011, at 12:27 PM, John Gammons wrote: >=20 > On Feb 3, 2011, at 11:20 AM, Keith Moore wrote: >=20 >> On Feb 3, 2011, at 10:54 AM, Sander Steffann wrote: >>=20 >>> Hi, >>>=20 >>>> On 2/3/2011 8:36 AM, Sander Steffann wrote: >>>>> - 6to4 MUST not be enabled by default >>>>>> - 6to4 SHOULD use a periodic reachability test to the relay = similar to what is specified in RFC5969 >>>>=20 >>>> Wouldn't these be reversed? If you mandate a reachability test to = make sure the 6to4 is valid, there's no problem with it enabled by = default. >>>=20 >>> I think not. I think enabling 6to4 should be a conscious decision. = After enabling 6to4 it should still be monitored to avoid problems at a = later time. So I think both suggestions are good. >>=20 >> I don't see why enabling 6to4 should be any more of a conscious = decision than enabling IPv4. >=20 > Agreed. While I see both sides of this argument, from a = CPE/Residential Gateway perspective, I think IPv6 should be enabled by = default. Attempting native IPv6, and falling back to 6to4, before = giving up (surprisingly similar to the way Microsoft has handled this = one). At this stage of the game, some level of IPv6 connectivity is = arguably a requirement. While not perfect, I think the argument can be = made that problematic V6 connectivity, is better than none. =20 >=20 > Expecting end-users to turn it on, only further escalates the = broken-ness. Given the complexity of the architecture and being able to = accurately weigh the benefits and disadvantages it provides, is = extremely difficult for the end-user, which will more often then not, = mean they "won't mess with that setting", shutting themselves out of V6 = land all together...=20 >=20 > If it is enabled by default in the CPEs, then it will only further the = requirements of all operators and content providers to do their part to = ensure it's effectiveness, thereby making it less broken, which is the = fundamental purpose of this draft. =20 >=20 > Excellent work on this draft btw, very useful to the community.... >=20 > John >=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From moore@network-heretics.com Fri Feb 4 08:17:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF363A6903 for ; Fri, 4 Feb 2011 08:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cZPzmlke4Lk for ; Fri, 4 Feb 2011 08:17:11 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id CA1773A697E for ; Fri, 4 Feb 2011 08:17:11 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PlOOh-0006sa-Sc; Fri, 04 Feb 2011 11:20:36 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: Date: Fri, 4 Feb 2011 11:20:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94046d263173428649197b75916ee024a78350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 X-Mailman-Approved-At: Fri, 04 Feb 2011 10:02:38 -0800 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 16:17:12 -0000 On Feb 4, 2011, at 11:12 AM, R=E9mi Despr=E9s wrote: >=20 > Le 3 f=E9vr. 2011 =E0 18:27, John Gammons a =E9crit : >=20 >> On Feb 3, 2011, at 11:20 AM, Keith Moore wrote: >>=20 >>> On Feb 3, 2011, at 10:54 AM, Sander Steffann wrote: >>>>=20 >>>> ... I think enabling 6to4 should be a conscious decision. >=20 > +1 >=20 >>>> After enabling 6to4 it should still be monitored to avoid problems = at a later time. So I think both suggestions are good. >>>=20 >>> I don't see why enabling 6to4 should be any more of a conscious = decision than enabling IPv4. >=20 > (I assume Keith meant enabling "IPv6".) No, actually I meant enabling 6to4. IMO, 6to4 should be enabled by = default on every host that has IPv4 connectivity and public address = space. =20 However I'm all for hosts having heuristics that avoid using 6to4 source = addresses to contact non-6to4 addresses if the anycast relay (or other = relay router) or return path is nonexistent or broken. Keith From tore.anderson@redpill-linpro.com Fri Feb 4 10:54:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59A873A67CC for ; Fri, 4 Feb 2011 10:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id na3CjCLWX+F4 for ; Fri, 4 Feb 2011 10:54:26 -0800 (PST) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id D86843A69CF for ; Fri, 4 Feb 2011 10:54:25 -0800 (PST) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 59094C429C; Fri, 4 Feb 2011 19:57:50 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mailhub.linpro.no Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id avwojM-E-sBA; Fri, 4 Feb 2011 19:57:41 +0100 (CET) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Fri, 4 Feb 2011 19:57:41 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id E0B58170C00C; Fri, 4 Feb 2011 19:57:41 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-su6Bgn7gsA; Fri, 4 Feb 2011 19:57:41 +0100 (CET) Received: from envy.fud.no (unknown [77.40.198.54]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 104EB170C00A; Fri, 4 Feb 2011 19:57:41 +0100 (CET) Message-ID: <4D4C4C24.3070209@redpill-linpro.com> Date: Fri, 04 Feb 2011 19:57:40 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> In-Reply-To: <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:54:27 -0000 * Keith Moore > IMO, 6to4 should be enabled by default on every host that has IPv4 > connectivity and public address space. > > However I'm all for hosts having heuristics that avoid using 6to4 > source addresses to contact non-6to4 addresses if the anycast relay > (or other relay router) or return path is nonexistent or broken. 6to4 isn't very harmful when terminated on hosts that do proper source address selection and use it as a last resort towards dual-stacked destinations. An example of this is how it's done in Microsoft Windows. (However, it has still caused problems with applications that don't use the OS-provided resolver interfaces, e.g., the Opera web browser.) The trouble start once you start *sharing* the 6to4 connectivity to other nodes on the network, such as implementing it in CPEs, «Internet Sharing»-type functionality on hosts, or similar. Those 6to4 routers cannot know whether or not the other nodes on the network are capable of doing proper source address selection. There are plenty that aren't. Therefore, 6to4 should *not* be enabled by default in any box that take on the role of a router - it makes the IPv6 end user experience suck. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From jgammons@gmail.com Fri Feb 4 10:56:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B875F3A694A for ; Fri, 4 Feb 2011 10:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur0PnsJ-pGP9 for ; Fri, 4 Feb 2011 10:56:25 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id A8F763A68F0 for ; Fri, 4 Feb 2011 10:56:25 -0800 (PST) Received: by vws7 with SMTP id 7so1776148vws.31 for ; Fri, 04 Feb 2011 10:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=p2u2hq+7V/rr56hLfEovE0up8LnwCBln9nd5kLPqCPI=; b=n+fEwu9JaHJGP2tzhQ2o8DvzinLBFuwzvgpXQck3rtCsGpVuUxkmj9FIWMRzBdSgUf eaO0OpuOql7DS8RB32v70MlztHy6HxrckTerZoE5roDt6Wxzzdygz16jA1F3FZ8wZ3Ac Pw82z0fBt3nLlH+mY+bEHoZ3B9qpmXq+ioioo= 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=kcY9ApMm+6tGFvl9K/NYXeS2QiNSRRvSDD1Vn7JemuyIEK9mFdtFzVNApcxeIORmIR ehVVaon7vqinlT2BFB/kdYEsk2Z3v8+6sqmi+2oAQNVvpbD9FuCje1EnAOFs/+73v+FP KCYMCoFbtpwtfSG/YXfEusH/CRFWwShKEVOtI= Received: by 10.220.178.137 with SMTP id bm9mr3323701vcb.98.1296845990960; Fri, 04 Feb 2011 10:59:50 -0800 (PST) Received: from [10.64.32.36] (gw1.cox.com [24.248.74.254]) by mx.google.com with ESMTPS id o13sm410669vch.40.2011.02.04.10.59.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 10:59:50 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: John Gammons In-Reply-To: <4D4C3E51.8070503@brightok.net> Date: Fri, 4 Feb 2011 13:59:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:56:26 -0000 On Feb 4, 2011, at 12:58 PM, Jack Bates wrote: > On 2/4/2011 11:40 AM, R=E9mi Despr=E9s wrote: >>> However, having 6to4 enabled does allow the device to reach an IPv6 >>> only host. >>=20 >> Some IPv6-only hosts, yes, but not all those that have native IPv6 >> addresses without having also IPv6 addresses. That's where the >> brokenness comes, and IMHO should be avoided. >>=20 >> I don't know how many servers are accessible ONLY in IPv6, and ONLY >> at native IPv6 addresses (i.e. without having also 6to4 addresses). >> But this is a configuration I wouldn't recommend for any server that >> has to be reachable also from 6to4 addresses. I agree, wherever possible IPv6 ONLY at the server level should be = avoided, but with IPv4 exhaustion approaching, this COULD (and arguably = will) become necessary for some content providers. This is why I feel = it is necessary to have 6to4 as a fallback connectivity option that is = enabled by "default" (with proper policies). The future will most likely result in more divergence of the two = protocols, supporting both legacy IPv4 only hosts/devices and native = IPv6 only content and desiring interconnectivity (6to4 when other = options aren't available) between the two.... well that's my prediction = at least.... and from a CPE perspective (again - provided proper policy = is in place), to have 6to4 enabled when all else fails, seems logical = and arguably a feature end-users should be entitled to without knowledge = of what "6to4" is. =20 >>=20 >=20 > If it's IPv6 only, it won't have a 6to4 address (otherwise it could be = reachable via IPv4). It is HIGHLY recommended that no content sites = should advertise 6to4 addressing. That said, it is highly recommended = that an IPv4 content site support 6to4 that isn't advertised. The reason = is that if a host uses 6to4 anycast to reach a native address = (overriding the proper policy), the server can actually reply directly = through the 6to4 interface. >=20 >>> They should always be handled differently. That is what should be >>> fixed if it is broken. >>=20 >> Yes. Until it is fixed, though, it remains safer that CPEs activate >> IPv6 by default only if their IPv6 prefixes are native (natively >> routed or with 6rd). >=20 > Except that this will break all IPv6 connectivity. If they can change = the code to be disabled, they should be able to change it to just = operate with the appropriate policy. I agree that it is better to = deactivate the 6to4 *IF* a CPE isn't going to use a policy. >=20 +1 >=20 > Jack John From brian.e.carpenter@gmail.com Fri Feb 4 11:38:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB103A69E3 for ; Fri, 4 Feb 2011 11:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.184 X-Spam-Level: X-Spam-Status: No, score=-103.184 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvqqCA4iODqz for ; Fri, 4 Feb 2011 11:38:12 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B7FCF3A69CF for ; Fri, 4 Feb 2011 11:38:11 -0800 (PST) Received: by fxm9 with SMTP id 9so2937940fxm.31 for ; Fri, 04 Feb 2011 11:41:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DTDtrHe1PvUMuS7lPQ45G8SjCQQ2zzoSn651ybKp7kc=; b=ctF475jYQ4aU0ulOzXEcQrjmUd0grmIIWB5ao5n6lpp2SJNzSDr3KFPF4YefKfVHgy DmsTcGRL7EMIZDEh//yAimWXcqWOcsiuYk9kAUMjO1cmSS99iZPK5WrQPDjGgMJORmB5 zcX+v9r2aUqHhV1NfoY7vqYfQ3PzVHngELF24= 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=vpYwm2FiUtQ0CpDGh6S5CGIEKfTKmdRfm/qyZlq3V8gLasg15M05xoMS+9GMNYuSoS yKmVqhvRHW/qmqh/sZZnLY/BDYFwFUCqg7Ny/dgYVTvVIKZ5S/CnEJSEWFccyR38tPwE vOeRgI6PY9ZlWRtl8YEzKhFfBBo6Y+DzP0mts= Received: by 10.223.74.5 with SMTP id s5mr11935379faj.72.1296848496830; Fri, 04 Feb 2011 11:41:36 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id n15sm397729fam.12.2011.02.04.11.41.25 (version=SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 11:41:29 -0800 (PST) Message-ID: <4D4C565F.1010405@gmail.com> Date: Sat, 05 Feb 2011 08:41:19 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John Gammons References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> In-Reply-To: <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 19:38:13 -0000 This discussion shows exactly why I scoped the draft *not* to include advice on host behaviour. As long as I'm editing it, I want to focus on advice to operators. Host behaviour is something done *to* operators, not *by* operators. If somebody else wants to write a draft that advises on host behaviour, go for it, but you'll have to make sense of this discussion, which has be= en going for years. Regards Brian On 2011-02-05 07:59, John Gammons wrote: > On Feb 4, 2011, at 12:58 PM, Jack Bates wrote: >=20 >> On 2/4/2011 11:40 AM, R=C3=A9mi Despr=C3=A9s wrote: >>>> However, having 6to4 enabled does allow the device to reach an IPv6 >>>> only host. >>> Some IPv6-only hosts, yes, but not all those that have native IPv6 >>> addresses without having also IPv6 addresses. That's where the >>> brokenness comes, and IMHO should be avoided. >>> >>> I don't know how many servers are accessible ONLY in IPv6, and ONLY >>> at native IPv6 addresses (i.e. without having also 6to4 addresses). >>> But this is a configuration I wouldn't recommend for any server that >>> has to be reachable also from 6to4 addresses. >=20 > I agree, wherever possible IPv6 ONLY at the server level should be avoi= ded, but with IPv4 exhaustion approaching, this COULD (and arguably will)= become necessary for some content providers. This is why I feel it is n= ecessary to have 6to4 as a fallback connectivity option that is enabled b= y "default" (with proper policies). >=20 > The future will most likely result in more divergence of the two protoc= ols, supporting both legacy IPv4 only hosts/devices and native IPv6 only = content and desiring interconnectivity (6to4 when other options aren't av= ailable) between the two.... well that's my prediction at least.... and f= rom a CPE perspective (again - provided proper policy is in place), to ha= ve 6to4 enabled when all else fails, seems logical and arguably a feature= end-users should be entitled to without knowledge of what "6to4" is. =20 >=20 >> If it's IPv6 only, it won't have a 6to4 address (otherwise it could be= reachable via IPv4). It is HIGHLY recommended that no content sites shou= ld advertise 6to4 addressing. That said, it is highly recommended that an= IPv4 content site support 6to4 that isn't advertised. The reason is that= if a host uses 6to4 anycast to reach a native address (overriding the pr= oper policy), the server can actually reply directly through the 6to4 int= erface. >=20 >>>> They should always be handled differently. That is what should be >>>> fixed if it is broken. >>> Yes. Until it is fixed, though, it remains safer that CPEs activate >>> IPv6 by default only if their IPv6 prefixes are native (natively >>> routed or with 6rd). >> Except that this will break all IPv6 connectivity. If they can change = the code to be disabled, they should be able to change it to just operate= with the appropriate policy. I agree that it is better to deactivate the= 6to4 *IF* a CPE isn't going to use a policy. >> >=20 > +1 >=20 >> Jack >=20 > John >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From Internet-Drafts@ietf.org Fri Feb 4 13:15:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3ADA3A69FB; Fri, 4 Feb 2011 13:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf5W7MW4wsom; Fri, 4 Feb 2011 13:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01FF3A69D3; Fri, 4 Feb 2011 13:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110204211501.23846.49997.idtracker@localhost> Date: Fri, 04 Feb 2011 13:15:01 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-tunnel-loops-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 21:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations Author(s) : G. Nakibly, F. Templin Filename : draft-ietf-v6ops-tunnel-loops-03.txt Pages : 14 Date : 2011-02-04 This document is concerned with security vulnerabilities in IPv6-in- IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop which can be abused as a vehicle for traffic amplification to facilitate DoS attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-tunnel-loops-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-tunnel-loops-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-04130415.I-D@ietf.org> --NextPart-- From jbates@brightok.net Fri Feb 4 13:19:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F5F83A694A for ; Fri, 4 Feb 2011 13:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vj33lcKZ859I for ; Fri, 4 Feb 2011 13:19:41 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 26A053A67C1 for ; Fri, 4 Feb 2011 13:19:41 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p14LN5bn001594; Fri, 4 Feb 2011 15:23:05 -0600 (CST) Message-ID: <4D4C6E39.4060200@brightok.net> Date: Fri, 04 Feb 2011 15:23:05 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian E Carpenter References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> In-Reply-To: <4D4C565F.1010405@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 21:19:42 -0000 Yeah, sorry. I did mention in one reply that it was out of scope. :) I do believe that server operators should support 6to4 on all servers that are dual stacked, but should never advertise a 6to4 prefix in DNS. This allows them to reply to 6to4 that comes in via native IPv6 directly and not rely on another gateway to drop it into 6to4. This also may be slightly out of scope of your draft. Jack On 2/4/2011 1:41 PM, Brian E Carpenter wrote: > This discussion shows exactly why I scoped the draft *not* to include > advice on host behaviour. As long as I'm editing it, I want to focus > on advice to operators. Host behaviour is something done *to* > operators, not *by* operators. > > If somebody else wants to write a draft that advises on host behaviour, > go for it, but you'll have to make sense of this discussion, which has been > going for years. > > Regards > Brian > > > On 2011-02-05 07:59, John Gammons wrote: >> On Feb 4, 2011, at 12:58 PM, Jack Bates wrote: >> >>> On 2/4/2011 11:40 AM, Rémi Després wrote: >>>>> However, having 6to4 enabled does allow the device to reach an IPv6 >>>>> only host. >>>> Some IPv6-only hosts, yes, but not all those that have native IPv6 >>>> addresses without having also IPv6 addresses. That's where the >>>> brokenness comes, and IMHO should be avoided. >>>> >>>> I don't know how many servers are accessible ONLY in IPv6, and ONLY >>>> at native IPv6 addresses (i.e. without having also 6to4 addresses). >>>> But this is a configuration I wouldn't recommend for any server that >>>> has to be reachable also from 6to4 addresses. >> >> I agree, wherever possible IPv6 ONLY at the server level should be avoided, but with IPv4 exhaustion approaching, this COULD (and arguably will) become necessary for some content providers. This is why I feel it is necessary to have 6to4 as a fallback connectivity option that is enabled by "default" (with proper policies). >> >> The future will most likely result in more divergence of the two protocols, supporting both legacy IPv4 only hosts/devices and native IPv6 only content and desiring interconnectivity (6to4 when other options aren't available) between the two.... well that's my prediction at least.... and from a CPE perspective (again - provided proper policy is in place), to have 6to4 enabled when all else fails, seems logical and arguably a feature end-users should be entitled to without knowledge of what "6to4" is. >> >>> If it's IPv6 only, it won't have a 6to4 address (otherwise it could be reachable via IPv4). It is HIGHLY recommended that no content sites should advertise 6to4 addressing. That said, it is highly recommended that an IPv4 content site support 6to4 that isn't advertised. The reason is that if a host uses 6to4 anycast to reach a native address (overriding the proper policy), the server can actually reply directly through the 6to4 interface. >> >>>>> They should always be handled differently. That is what should be >>>>> fixed if it is broken. >>>> Yes. Until it is fixed, though, it remains safer that CPEs activate >>>> IPv6 by default only if their IPv6 prefixes are native (natively >>>> routed or with 6rd). >>> Except that this will break all IPv6 connectivity. If they can change the code to be disabled, they should be able to change it to just operate with the appropriate policy. I agree that it is better to deactivate the 6to4 *IF* a CPE isn't going to use a policy. >>> >> >> +1 >> >>> Jack >> >> John >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From sander@steffann.nl Fri Feb 4 14:47:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA33B3A6A13 for ; Fri, 4 Feb 2011 14:47:28 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wxsoJL+Fvhu for ; Fri, 4 Feb 2011 14:47:28 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by core3.amsl.com (Postfix) with ESMTP id 565D03A6A0D for ; Fri, 4 Feb 2011 14:47:27 -0800 (PST) Received: from macpro.10ww.steffann.nl (unknown [IPv6:2001:610:6ce:1:224:36ff:feef:1d89]) by mail.sintact.nl (Postfix) with ESMTP id F10332006 for ; Fri, 4 Feb 2011 23:50:51 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Sander Steffann In-Reply-To: <4D4C6E39.4060200@brightok.net> Date: Fri, 4 Feb 2011 23:50:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <862B9854-AACC-427A-BC71-CA5B4177BADD@steffann.nl> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> To: IPv6 Operations X-Mailer: Apple Mail (2.1082) Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 22:47:28 -0000 > I do believe that server operators should support 6to4 on all servers = that are dual stacked, but should never advertise a 6to4 prefix in DNS. = This allows them to reply to 6to4 that comes in via native IPv6 directly = and not rely on another gateway to drop it into 6to4. Good advise. I would still recommend ISPs to provide a reliable 6to4 = relay in case hosts don't do this though. But you probably already understood that :) Sander From brian.e.carpenter@gmail.com Fri Feb 4 14:50:35 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D47923A6A13 for ; Fri, 4 Feb 2011 14:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.168 X-Spam-Level: X-Spam-Status: No, score=-103.168 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIDc+KD5YfRi for ; Fri, 4 Feb 2011 14:50:34 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 2E50A3A6A32 for ; Fri, 4 Feb 2011 14:50:34 -0800 (PST) Received: by qwi2 with SMTP id 2so2323397qwi.31 for ; Fri, 04 Feb 2011 14:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vebdoOXsYDrjm2h3U0enJpdUyIV0bclsK9/zjccBIo4=; b=omBJnUP1zhncwSNMbWxci0jGTEhr9qVZdAXxi7SHN6GRh0AdzmCZIjkBbOP95oRJYK C1E/2cb5MMrmaliVs9ek6zakp4XqKiwpX7vXFbiD5TuVFIz8cLVhmBSoQUsNZoioxayx EMKurtosTXceNvvC7CtQ1P8Ys0sn5UBuZJWtE= 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=EVJTRdoKbAbwAYIViwcaaRCo4kNlWAYmZke80bd4F6/0ivXioATNCzFidaoW0bbonJ DtnSieuI04rFnb5EnPuOYAzDXIxbcVnSVkDPO01XIKfznXJh4jMbSHkSEKyNP98zQ+Yl nwsGOZR4SXlhbasGwmKyaE34WGjsByncBupi0= Received: by 10.224.60.149 with SMTP id p21mr8767375qah.180.1296860039910; Fri, 04 Feb 2011 14:53:59 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id y17sm804830qci.45.2011.02.04.14.53.56 (version=SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 14:53:59 -0800 (PST) Message-ID: <4D4C837F.8020306@gmail.com> Date: Sat, 05 Feb 2011 11:53:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jack Bates References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> In-Reply-To: <4D4C6E39.4060200@brightok.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 22:50:36 -0000 On 2011-02-05 10:23, Jack Bates wrote: > Yeah, sorry. I did mention in one reply that it was out of scope. :) >=20 > I do believe that server operators should support 6to4 on all servers > that are dual stacked, but should never advertise a 6to4 prefix in DNS.= > This allows them to reply to 6to4 that comes in via native IPv6 directl= y > and not rely on another gateway to drop it into 6to4. >=20 > This also may be slightly out of scope of your draft. Actually, no, we have that in as advice to content providers. Brian >=20 > Jack >=20 > On 2/4/2011 1:41 PM, Brian E Carpenter wrote: >> This discussion shows exactly why I scoped the draft *not* to include >> advice on host behaviour. As long as I'm editing it, I want to focus >> on advice to operators. Host behaviour is something done *to* >> operators, not *by* operators. >> >> If somebody else wants to write a draft that advises on host behaviour= , >> go for it, but you'll have to make sense of this discussion, which has= >> been >> going for years. >> >> Regards >> Brian >> >> >> On 2011-02-05 07:59, John Gammons wrote: >>> On Feb 4, 2011, at 12:58 PM, Jack Bates wrote: >>> >>>> On 2/4/2011 11:40 AM, R=C3=A9mi Despr=C3=A9s wrote: >>>>>> However, having 6to4 enabled does allow the device to reach an IPv= 6 >>>>>> only host. >>>>> Some IPv6-only hosts, yes, but not all those that have native IPv6 >>>>> addresses without having also IPv6 addresses. That's where the >>>>> brokenness comes, and IMHO should be avoided. >>>>> >>>>> I don't know how many servers are accessible ONLY in IPv6, and ONLY= >>>>> at native IPv6 addresses (i.e. without having also 6to4 addresses).= >>>>> But this is a configuration I wouldn't recommend for any server tha= t >>>>> has to be reachable also from 6to4 addresses. >>> >>> I agree, wherever possible IPv6 ONLY at the server level should be >>> avoided, but with IPv4 exhaustion approaching, this COULD (and >>> arguably will) become necessary for some content providers. This is >>> why I feel it is necessary to have 6to4 as a fallback connectivity >>> option that is enabled by "default" (with proper policies). >>> >>> The future will most likely result in more divergence of the two >>> protocols, supporting both legacy IPv4 only hosts/devices and native >>> IPv6 only content and desiring interconnectivity (6to4 when other >>> options aren't available) between the two.... well that's my >>> prediction at least.... and from a CPE perspective (again - provided >>> proper policy is in place), to have 6to4 enabled when all else fails,= >>> seems logical and arguably a feature end-users should be entitled to >>> without knowledge of what "6to4" is. >>> >>>> If it's IPv6 only, it won't have a 6to4 address (otherwise it could >>>> be reachable via IPv4). It is HIGHLY recommended that no content >>>> sites should advertise 6to4 addressing. That said, it is highly >>>> recommended that an IPv4 content site support 6to4 that isn't >>>> advertised. The reason is that if a host uses 6to4 anycast to reach >>>> a native address (overriding the proper policy), the server can >>>> actually reply directly through the 6to4 interface. >>> >>>>>> They should always be handled differently. That is what should be >>>>>> fixed if it is broken. >>>>> Yes. Until it is fixed, though, it remains safer that CPEs activate= >>>>> IPv6 by default only if their IPv6 prefixes are native (natively >>>>> routed or with 6rd). >>>> Except that this will break all IPv6 connectivity. If they can >>>> change the code to be disabled, they should be able to change it to >>>> just operate with the appropriate policy. I agree that it is better >>>> to deactivate the 6to4 *IF* a CPE isn't going to use a policy. >>>> >>> >>> +1 >>> >>>> Jack >>> >>> John >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >=20 From jbates@brightok.net Fri Feb 4 17:58:18 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847333A6875 for ; Fri, 4 Feb 2011 17:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.767 X-Spam-Level: X-Spam-Status: No, score=-2.767 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcTOh82ndGO2 for ; Fri, 4 Feb 2011 17:58:17 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 9C7403A659C for ; Fri, 4 Feb 2011 17:58:17 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p1521hux000922 for ; Fri, 4 Feb 2011 20:01:43 -0600 (CST) Message-ID: <4D4CAF74.2030200@brightok.net> Date: Fri, 04 Feb 2011 20:01:24 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPv6 Operations References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <862B9854-AACC-427A-BC71-CA5B4177BADD@steffann.nl> In-Reply-To: <862B9854-AACC-427A-BC71-CA5B4177BADD@steffann.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 01:58:18 -0000 On 2/4/2011 4:50 PM, Sander Steffann wrote: > Good advise. I would still recommend ISPs to provide a reliable 6to4 relay in case hosts don't do this though. > As an ISP, we deployed 6to4 relays years ago, not because we wanted to fix IPv6 connectivity per se, but because there was a 6to4 relay being announced in BGP and it's IPv6 connectivity sucked. It's wise to have the IPv6 anycast (which is actually what many ISPs forget to do and breaks replies) and to have the IPv4 anycast (to keep packets from finding their way to broken IPv6 networks). I've been swamped and have to reread the draft, but I think it covered both cases. Jack From wwwrun@rfc-editor.org Sun Feb 6 05:26:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824B63A6778 for ; Sun, 6 Feb 2011 05:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.001 X-Spam-Level: X-Spam-Status: No, score=-101.001 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSPEU1S-G7dk for ; Sun, 6 Feb 2011 05:26:16 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id E23CC3A6A50 for ; Sun, 6 Feb 2011 05:26:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9F888E0701; Sun, 6 Feb 2011 05:26:12 -0800 (PST) To: elwynd@dial.pipex.com, mohacsi@niif.hu, dromasca@avaya.com, rbonica@juniper.net, fred.baker@cisco.com, joelja@bogus.com, kurtis@kurtis.pp.se From: RFC Errata System Message-Id: <20110206132612.9F888E0701@rfc-editor.org> Date: Sun, 6 Feb 2011 05:26:12 -0800 (PST) X-Mailman-Approved-At: Sun, 06 Feb 2011 09:17:45 -0800 Cc: phil.whineray@gmail.com, v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] [Technical Errata Reported] RFC4890 (2706) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 13:26:17 -0000 The following errata report has been submitted for RFC4890, "Recommendations for Filtering ICMPv6 Messages in Firewalls". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4890&eid=2706 -------------------------------------- Type: Technical Reported by: Phil Whineray Section: Appendix B. Original Text ------------- if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming time exceeded code 0 messages # only for existing sessions for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ -j ACCEPT done else # Allow incoming time exceeded code 0 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type ttl-zero-during-transit -j ACCEPT done fi Corrected Text -------------- if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming time exceeded code 0 messages # only for existing sessions for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED --icmpv6-type ttl-zero-during-transmit \ -j ACCEPT done else # Allow incoming time exceeded code 0 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type ttl-zero-during-transit -j ACCEPT done fi Notes ----- Not sure if this is really editorial as it is in the example code, not the main RFC. In any case, the example incorrectly specifies an icmpv6 type in one code path. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4890 (draft-ietf-v6ops-icmpv6-filtering-recs-03) -------------------------------------- Title : Recommendations for Filtering ICMPv6 Messages in Firewalls Publication Date : May 2007 Author(s) : E. Davies, J. Mohacsi Category : INFORMATIONAL Source : IPv6 Operations Area : Operations and Management Stream : IETF Verifying Party : IESG From Internet-Drafts@ietf.org Sun Feb 6 10:00:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78E13A6966; Sun, 6 Feb 2011 10:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.831 X-Spam-Level: X-Spam-Status: No, score=-101.831 tagged_above=-999 required=5 tests=[AWL=0.768, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6e7XTfpFnh7; Sun, 6 Feb 2011 10:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55873A68CB; Sun, 6 Feb 2011 10:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110206180001.20946.52252.idtracker@localhost> Date: Sun, 06 Feb 2011 10:00:01 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 18:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 AAAA DNS Whitelisting Implications Author(s) : J. Livingood Filename : draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02.txt Pages : 30 Date : 2011-02-06 The objective of this document is to describe what whitelisting of DNS AAAA resource records is, or DNS whitelisting for short, as well as what the implications of this emerging practice are and what alternatives may exist. The audience for this document is the Internet community generally, including the IETF and IPv6 implementers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-06095757.I-D@ietf.org> --NextPart-- From joelja@bogus.com Sun Feb 6 19:35:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6CF83A6C94 for ; Sun, 6 Feb 2011 19:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuIwH8-STddG for ; Sun, 6 Feb 2011 19:35:44 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id B20EE3A6C93 for ; Sun, 6 Feb 2011 19:35:43 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p173Za7G060598 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Mon, 7 Feb 2011 03:35:44 GMT (envelope-from joelja@bogus.com) Message-ID: <4D4F6887.7050203@bogus.com> Date: Sun, 06 Feb 2011 19:35:35 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPv6 Ops WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 03:35:45 -0000 This announcement is to serve as the beginning of the WGLC for: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 WGLC runs from Monday Feb 7th to Monday Feb 21st. The 01 version of this document received a lot of good feedback on this list which has been incorporated into this version of the draft. joelja From remi.despres@free.fr Mon Feb 7 00:31:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000043A6CF8 for ; Mon, 7 Feb 2011 00:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.651 X-Spam-Level: X-Spam-Status: No, score=0.651 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+2ShALXY4js for ; Mon, 7 Feb 2011 00:31:48 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by core3.amsl.com (Postfix) with ESMTP id D62013A6CF7 for ; Mon, 7 Feb 2011 00:31:47 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id D5A7E700008B; Mon, 7 Feb 2011 09:31:50 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id 6B2737000082; Mon, 7 Feb 2011 09:31:50 +0100 (CET) X-SFR-UUID: 20110207083150438.6B2737000082@msfrf2409.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D4C3E51.8070503@brightok.net> Date: Mon, 7 Feb 2011 09:31:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8469C978-D60E-45AD-A534-A8E989DB8374@free.fr> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 08:31:49 -0000 Hello Jack, This is indeed an interesting discussion. I hope we can converge. Le 4 f=E9vr. 2011 =E0 18:58, Jack Bates a =E9crit : > On 2/4/2011 11:40 AM, R=E9mi Despr=E9s wrote: >>> However, having 6to4 enabled does allow the device to reach an IPv6 >>> only host. >>=20 >> Some IPv6-only hosts, yes, but not all those that have native IPv6 >> addresses without having also IPv6 addresses. That's where the >> brokenness comes, and IMHO should be avoided. >>=20 >> I don't know how many servers are accessible ONLY in IPv6, and ONLY >> at native IPv6 addresses (i.e. without having also 6to4 addresses). >> But this is a configuration I wouldn't recommend for any server that >> has to be reachable also from 6to4 addresses. >>=20 >=20 > If it's IPv6 only, it won't have a 6to4 address (otherwise it could be = reachable via IPv4). This statement isn't completely right because a server having a 6to4 = address can be unreachable in IPv4. Let's take a server that has both: - a private IPv4 address (the CPE has a NAT44) - a 6to4 address (the CPE has a public IPv4 address from which it = derives a 6to4 prefix) This server is reachable in IPv6 at its 6to4 address, but isn't = reachable in IPv4 because of the NAT.=20 Now, in a site that has both a native IPv6 prefix and a 6to4 prefix (in = the same CPE or in separate CPEs), each of its servers can have both a = native IPv6 address and a 6to4 address. Then, address-selection rules of RFC 3484 are such that: - Its native address will be used with native-address clients. - Its 6to4 address will be used by 6to4-address clients.=20 (A client whose only IPv6 address is 6to4 chooses the 6to4 server = address because, according to Rule 5 of RFC 3484, it has the same = "label" as the client's in the RFC-3484 policy table.) Thus, a server that advertises a native IPv6 address AND an 6to4 address = becomes reachable by 6to4 clients even if they have no access to 6to4 = relays.=20 Reachability is thus increased, and I haven't found any adverse effect. Do you see any? > It is HIGHLY recommended that no content sites should advertise 6to4 = addressing. Agreed that a server shouldn't advertise a 6to4 address as SOLE IPv6 = address. But, as explained above, advertising a 6to4 address IN ADDITION to a = native IPv6 addresses is useful to increase reachability. > That said, it is highly recommended that an IPv4 content site support = 6to4 Agreed... > that isn't advertised. Agreed only partially, see above. >> ... it remains safer that CPEs activate IPv6 by default only if their = IPv6 prefixes are native (natively routed or with 6rd). >=20 > Except that this will break all IPv6 connectivity. I didn't understand what you mean by breaking ALL IPv6 connectivity. (IPv6 connectivity between NATIVE addresses can't be broken by = requesting that 6to4 be enabled in CPEs only by a conscious decision.) > If they can change the code to be disabled, they should be able to = change it to just operate with the appropriate policy. I agree that it = is better to deactivate the 6to4 *IF* a CPE isn't going to use a policy. Agreed. In any case, all of this will become history when native IPv6 = availability is generalized (natively routed or with 6rd). Regards, RD From remi.despres@free.fr Mon Feb 7 05:49:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29303A6936 for ; Mon, 7 Feb 2011 05:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.581 X-Spam-Level: X-Spam-Status: No, score=0.581 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_20=-0.74, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlX-Afz1YbhK for ; Mon, 7 Feb 2011 05:48:59 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by core3.amsl.com (Postfix) with ESMTP id 5ADDD3A6DFD for ; Mon, 7 Feb 2011 05:48:59 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2421.sfr.fr (SMTP Server) with ESMTP id EFA2C7000086; Mon, 7 Feb 2011 14:49:02 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2421.sfr.fr (SMTP Server) with ESMTP id 131F97000092; Mon, 7 Feb 2011 14:49:02 +0100 (CET) X-SFR-UUID: 20110207134902783.131F97000092@msfrf2421.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D4C837F.8020306@gmail.com> Date: Mon, 7 Feb 2011 14:49:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 13:49:00 -0000 Le 4 f=E9vr. 2011 =E0 23:53, Brian E Carpenter a =E9crit : > On 2011-02-05 10:23, Jack Bates wrote: >> Yeah, sorry. I did mention in one reply that it was out of scope. :) >>=20 >> I do believe that server operators should support 6to4 on all servers >> that are dual stacked, but should never advertise a 6to4 prefix in = DNS. >> This allows them to reply to 6to4 that comes in via native IPv6 = directly >> and not rely on another gateway to drop it into 6to4. >>=20 >> This also may be slightly out of scope of your draft. >=20 > Actually, no, we have that in as advice to content providers. In my understanding: - The advice in the draft is that content-provider ISPs, and possibly = servers themselves, have 6to4 "relay" functions. - What Jack suggests is that servers themselves: . have 6to4 "router" functions (an therefore their own 6to4 = addresses); . don't advertise these 6to4 addresses - A better combination, in a server that has both a public IPv4 address = and a native IPv6 address, is that: . The server has the 6to4 "router function"=20 . In IPv6, both the native and the 6to4 addresses are advertised. An explanation is given in my last answer to Jack. If this is wrong, I look forward to explanations why. If this is right, something could advantageously added to your section = 2.3.4 (IMHO). Regards, RD >=20 > Brian >=20 >>=20 >> Jack >>=20 >> On 2/4/2011 1:41 PM, Brian E Carpenter wrote: >>> This discussion shows exactly why I scoped the draft *not* to = include >>> advice on host behaviour. As long as I'm editing it, I want to focus >>> on advice to operators. Host behaviour is something done *to* >>> operators, not *by* operators. >>>=20 >>> If somebody else wants to write a draft that advises on host = behaviour, >>> go for it, but you'll have to make sense of this discussion, which = has >>> been >>> going for years. >>>=20 >>> Regards >>> Brian >>>=20 >>>=20 >>> On 2011-02-05 07:59, John Gammons wrote: >>>> On Feb 4, 2011, at 12:58 PM, Jack Bates wrote: >>>>=20 >>>>> On 2/4/2011 11:40 AM, R=E9mi Despr=E9s wrote: >>>>>>> However, having 6to4 enabled does allow the device to reach an = IPv6 >>>>>>> only host. >>>>>> Some IPv6-only hosts, yes, but not all those that have native = IPv6 >>>>>> addresses without having also IPv6 addresses. That's where the >>>>>> brokenness comes, and IMHO should be avoided. >>>>>>=20 >>>>>> I don't know how many servers are accessible ONLY in IPv6, and = ONLY >>>>>> at native IPv6 addresses (i.e. without having also 6to4 = addresses). >>>>>> But this is a configuration I wouldn't recommend for any server = that >>>>>> has to be reachable also from 6to4 addresses. >>>>=20 >>>> I agree, wherever possible IPv6 ONLY at the server level should be >>>> avoided, but with IPv4 exhaustion approaching, this COULD (and >>>> arguably will) become necessary for some content providers. This = is >>>> why I feel it is necessary to have 6to4 as a fallback connectivity >>>> option that is enabled by "default" (with proper policies). >>>>=20 >>>> The future will most likely result in more divergence of the two >>>> protocols, supporting both legacy IPv4 only hosts/devices and = native >>>> IPv6 only content and desiring interconnectivity (6to4 when other >>>> options aren't available) between the two.... well that's my >>>> prediction at least.... and from a CPE perspective (again - = provided >>>> proper policy is in place), to have 6to4 enabled when all else = fails, >>>> seems logical and arguably a feature end-users should be entitled = to >>>> without knowledge of what "6to4" is. >>>>=20 >>>>> If it's IPv6 only, it won't have a 6to4 address (otherwise it = could >>>>> be reachable via IPv4). It is HIGHLY recommended that no content >>>>> sites should advertise 6to4 addressing. That said, it is highly >>>>> recommended that an IPv4 content site support 6to4 that isn't >>>>> advertised. The reason is that if a host uses 6to4 anycast to = reach >>>>> a native address (overriding the proper policy), the server can >>>>> actually reply directly through the 6to4 interface. >>>>=20 >>>>>>> They should always be handled differently. That is what should = be >>>>>>> fixed if it is broken. >>>>>> Yes. Until it is fixed, though, it remains safer that CPEs = activate >>>>>> IPv6 by default only if their IPv6 prefixes are native (natively >>>>>> routed or with 6rd). >>>>> Except that this will break all IPv6 connectivity. If they can >>>>> change the code to be disabled, they should be able to change it = to >>>>> just operate with the appropriate policy. I agree that it is = better >>>>> to deactivate the 6to4 *IF* a CPE isn't going to use a policy. >>>>>=20 >>>>=20 >>>> +1 >>>>=20 >>>>> Jack >>>>=20 >>>> John >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jbates@brightok.net Mon Feb 7 05:49:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A6D3A6E0E for ; Mon, 7 Feb 2011 05:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.965 X-Spam-Level: X-Spam-Status: No, score=-2.965 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANgNdJeaUeBA for ; Mon, 7 Feb 2011 05:49:10 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id B65BD3A6E0A for ; Mon, 7 Feb 2011 05:49:10 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17DnCGH027838; Mon, 7 Feb 2011 07:49:12 -0600 (CST) Message-ID: <4D4FF856.6040306@brightok.net> Date: Mon, 07 Feb 2011 07:49:10 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <8469C978-D60E-45AD-A534-A8E989DB8374@free.fr> In-Reply-To: <8469C978-D60E-45AD-A534-A8E989DB8374@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 13:49:11 -0000 On 2/7/2011 2:31 AM, Rémi Després wrote: > Hello Jack, > > This is indeed an interesting discussion. > I hope we can converge. > This statement isn't completely right because a server having a 6to4 address can be unreachable in IPv4. > Let's take a server that has both: > - a private IPv4 address (the CPE has a NAT44) > - a 6to4 address (the CPE has a public IPv4 address from which it derives a 6to4 prefix) > This server is reachable in IPv6 at its 6to4 address, but isn't reachable in IPv4 because of the NAT. > In this particular scenario, advertising a 6to4 address increases reachability; as it doesn't require the client to have an anycast 6to4 relay to get to the native IPv6 address; ie, it will keep some 6to4 clients from breaking. > Agreed that a server shouldn't advertise a 6to4 address as SOLE IPv6 > address. > But, as explained above, advertising a 6to4 address IN ADDITION to a native IPv6 addresses is useful to increase reachability. > Only if the server isn't advertising an IPv4 address. This is why, traditionally, 6to4 advertisements are usually private servers served out of homes behind NAT routers. >> That said, it is highly recommended that an IPv4 content site support 6to4 > Agreed... > >> that isn't advertised. > Agreed only partially, see above. > > Here you should agree fully. It's an IPv4 content site. If it's reachable via IPv4, it should NOT have a 6to4 address advertised at this point. Advertising 6to4 is likely to cause more breaks than the IPv4 advertisement. >>> ... it remains safer that CPEs activate IPv6 by default only if their IPv6 prefixes are native (natively routed or with 6rd). >> Except that this will break all IPv6 connectivity. > I didn't understand what you mean by breaking ALL IPv6 connectivity. > (IPv6 connectivity between NATIVE addresses can't be broken by requesting that 6to4 be enabled in CPEs only by a conscious decision.) > Lack of native connectivity or 6rd would leave the CPE with no IPv6 connectivity if 6to4 is disabled. In the case of IPv6 only sites, there is no way to reach them. >> If they can change the code to be disabled, they should be able to change it to just operate with the appropriate policy. I agree that it is better to deactivate the 6to4 *IF* a CPE isn't going to use a policy. > Agreed. > > In any case, all of this will become history when native IPv6 availability is generalized (natively routed or with 6rd). > Possibly, unless the ISP is expecting 6to4 instead of 6rd. As an engineer that manages 11 telco networks with diverse topologies, I've broken things down into general sets. 1) Serving Native IPv6 where all equipment supports it (a majority of them, luckily) 2) Serving 6rd where IPv6 is not compatible AND IPv4 is used in policy decisions (until the traffic shapers support v6, in other words). Alternatively, we may create static tunnels as we consider 6rd somewhat wasteful. 3) PPPoE areas are strictly native period. 4) Depend on 6to4 in all areas that haven't transitioned. 5) No IPv6 support on dialups. They'll now get to use the proxy servers for IPv6 connectivity in addition to the compress support (so called dialup acceleration). This is subject to change, as we may create a single upgraded pool and pseudowire the T1s from each telco over mpls to combine the entire set of dialup customers. Jack From jbates@brightok.net Mon Feb 7 05:59:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B62B3A6D90 for ; Mon, 7 Feb 2011 05:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.965 X-Spam-Level: X-Spam-Status: No, score=-2.965 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMdCTbJBB8Qx for ; Mon, 7 Feb 2011 05:59:08 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 91DBB3A68E0 for ; Mon, 7 Feb 2011 05:59:08 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17Dx7bL029781; Mon, 7 Feb 2011 07:59:07 -0600 (CST) Message-ID: <4D4FFAA9.2040306@brightok.net> Date: Mon, 07 Feb 2011 07:59:05 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 13:59:09 -0000 On 2/7/2011 7:49 AM, Rémi Després wrote: > > In my understanding: > - The advice in the draft is that content-provider ISPs, and possibly servers themselves, have 6to4 "relay" functions. > - What Jack suggests is that servers themselves: > . have 6to4 "router" functions (an therefore their own 6to4 addresses); > . don't advertise these 6to4 addresses > - A better combination, in a server that has both a public IPv4 address and a native IPv6 address, is that: > . The server has the 6to4 "router function" > . In IPv6, both the native and the 6to4 addresses are advertised. > An explanation is given in my last answer to Jack. > I'd argue that, - All servers with IPv6 connectivity have the 6to4 "router function" - If server advertises a IPv4 addresses, do NOT advertise 6to4 addresses - if server does not advertise IPv4, DO advertise 6to4 address Summary of my explanation: - If IPv4 connectivity is available, clients need to use it and not 6to4 addresses - If IPv4 is not available, clients should use 6to4 direct over anycasting. I'm still unsure on this last one, but I'm reasonably sure that anything which would break direct 6to4 connectivity will break using anycasting as well (unless some NAT66 took place). Jack From jbates@brightok.net Mon Feb 7 06:19:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485333A68EC for ; Mon, 7 Feb 2011 06:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.115 X-Spam-Level: X-Spam-Status: No, score=-3.115 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrO+ZA5YHrzk for ; Mon, 7 Feb 2011 06:19:20 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 79D433A691C for ; Mon, 7 Feb 2011 06:19:20 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17EJMg4004157; Mon, 7 Feb 2011 08:19:22 -0600 (CST) Message-ID: <4D4FFF68.2000403@brightok.net> Date: Mon, 07 Feb 2011 08:19:20 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> In-Reply-To: <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 14:19:21 -0000 On 2/7/2011 8:07 AM, Keith Moore wrote: > It seems to me that servers which support all of (native v6, 6to4, v4) will be more reachable than servers which support only (native v6, v4), because there will be v6-only hosts that sit behind 6to4 routers (each with only an external v4 connection) and those hosts will therefore be assigned a 6to4 address but not a native v6 address. The problem with your client side layout is that it is very specific. - If we are referring to a CPE, there is no reason they should not be doing IPv4 NAT AND 6to4 - If we are referring to an ISP network layout, the ISP will need to fix the network. The argument/benefit of 6to4 over IPv4 is support for end to end connectivity when you have a 6to4 CPE. The problem is that 6to4 often breaks (and will break more often with CGN) more than using IPv4. Advertising a 6to4 address on a server which supports IPv4 will cause more connectivity issues, especially as CGN takes effect. Jack From moore@network-heretics.com Mon Feb 7 06:08:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A263A6909 for ; Mon, 7 Feb 2011 06:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PM8AN-acKjgy for ; Mon, 7 Feb 2011 06:08:04 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 967163A6E04 for ; Mon, 7 Feb 2011 06:08:01 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmRl5-00033n-Ql; Mon, 07 Feb 2011 09:08:04 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: <4D4FFAA9.2040306@brightok.net> Date: Mon, 7 Feb 2011 09:07:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940ef8998d005eea4eea27b7188b4740125350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 X-Mailman-Approved-At: Mon, 07 Feb 2011 06:20:47 -0800 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 14:08:05 -0000 On Feb 7, 2011, at 8:59 AM, Jack Bates wrote: > On 2/7/2011 7:49 AM, R=E9mi Despr=E9s wrote: >>=20 >> In my understanding: >> - The advice in the draft is that content-provider ISPs, and possibly = servers themselves, have 6to4 "relay" functions. >> - What Jack suggests is that servers themselves: >> . have 6to4 "router" functions (an therefore their own 6to4 = addresses); >> . don't advertise these 6to4 addresses >> - A better combination, in a server that has both a public IPv4 = address and a native IPv6 address, is that: >> . The server has the 6to4 "router function" >> . In IPv6, both the native and the 6to4 addresses are advertised. >> An explanation is given in my last answer to Jack. >>=20 >=20 > I'd argue that, >=20 > - All servers with IPv6 connectivity have the 6to4 "router function" > - If server advertises a IPv4 addresses, do NOT advertise 6to4 = addresses > - if server does not advertise IPv4, DO advertise 6to4 address >=20 > Summary of my explanation: > - If IPv4 connectivity is available, clients need to use it and not = 6to4 addresses > - If IPv4 is not available, clients should use 6to4 direct over = anycasting. >=20 > I'm still unsure on this last one, but I'm reasonably sure that = anything which would break direct 6to4 connectivity will break using = anycasting as well (unless some NAT66 took place). It seems to me that servers which support all of (native v6, 6to4, v4) = will be more reachable than servers which support only (native v6, v4), = because there will be v6-only hosts that sit behind 6to4 routers (each = with only an external v4 connection) and those hosts will therefore be = assigned a 6to4 address but not a native v6 address. =20 Keith From remi.despres@free.fr Mon Feb 7 06:33:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F131C3A6909 for ; Mon, 7 Feb 2011 06:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.684 X-Spam-Level: X-Spam-Status: No, score=-0.684 tagged_above=-999 required=5 tests=[AWL=1.265, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubW9s-l-CCNc for ; Mon, 7 Feb 2011 06:33:24 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by core3.amsl.com (Postfix) with ESMTP id EF1AE3A68C6 for ; Mon, 7 Feb 2011 06:33:23 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id 78E527000097; Mon, 7 Feb 2011 15:33:27 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id B0C687000091; Mon, 7 Feb 2011 15:33:26 +0100 (CET) X-SFR-UUID: 20110207143326724.B0C687000091@msfrf2212.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> Date: Mon, 7 Feb 2011 15:33:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 14:33:25 -0000 Le 7 f=E9vr. 2011 =E0 15:07, Keith Moore a =E9crit : > On Feb 7, 2011, at 8:59 AM, Jack Bates wrote: >>=20 >> I'd argue that, >>=20 >> - All servers with IPv6 connectivity have the 6to4 "router function" Not all of them: - If they have private IPv4 addresses, they can't have the 6to4 router = function. >> - If server advertises a IPv4 addresses, do NOT advertise 6to4 = addresses See Keith's point below. >> - if server does not advertise IPv4, DO advertise 6to4 address Only if a native address is also advertised (otherwise, reachability = from hosts whose only IPv6 address is native may have broken = connectivity). >> Summary of my explanation: >> - If IPv4 connectivity is available, clients need to use it and not = 6to4 addresses >> - If IPv4 is not available, clients should use 6to4 direct over = anycasting. >>=20 >> I'm still unsure on this last one, but I'm reasonably sure that = anything which would break direct 6to4 connectivity will break using = anycasting as well (unless some NAT66 took place). >=20 > It seems to me that servers which support all of (native v6, 6to4, v4) = will be more reachable than servers which support only (native v6, v4), = because there will be v6-only hosts that sit behind 6to4 routers (each = with only an external v4 connection) and those hosts will therefore be = assigned a 6to4 address but not a native v6 address. Same understanding. Regards, RD From remi.despres@free.fr Mon Feb 7 06:37:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B8E3A6936 for ; Mon, 7 Feb 2011 06:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdlL3paizT+D for ; Mon, 7 Feb 2011 06:37:20 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by core3.amsl.com (Postfix) with ESMTP id A36003A691C for ; Mon, 7 Feb 2011 06:37:19 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id A889A700009A; Mon, 7 Feb 2011 15:37:23 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id 646EE7000091; Mon, 7 Feb 2011 15:37:23 +0100 (CET) X-SFR-UUID: 20110207143723411.646EE7000091@msfrf2212.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D4FFF68.2000403@brightok.net> Date: Mon, 7 Feb 2011 15:37:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <96AAB522-4179-45BC-8FC3-A4EF1A7509A4@free.fr> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 14:37:20 -0000 Le 7 f=E9vr. 2011 =E0 15:19, Jack Bates a =E9crit : > On 2/7/2011 8:07 AM, Keith Moore wrote: >> It seems to me that servers which support all of (native v6, 6to4, = v4) will be more reachable than servers which support only (native v6, = v4), because there will be v6-only hosts that sit behind 6to4 routers = (each with only an external v4 connection) and those hosts will = therefore be assigned a 6to4 address but not a native v6 address. >=20 > The problem with your client side layout is that it is very specific. >=20 > - If we are referring to a CPE, there is no reason they should not be = doing IPv4 NAT AND 6to4 > - If we are referring to an ISP network layout, the ISP will need to = fix the network. >=20 > The argument/benefit of 6to4 over IPv4 is support for end to end = connectivity when you have a 6to4 CPE. Agreed. > The problem is that 6to4 often breaks (and will break more often with = CGN) more than using IPv4. 6to4 breaks in case of native IPv6 clients connecting to 6to4 servers, = but not between two 6to4 addresses. > Advertising a 6to4 address on a server which supports IPv4 will cause = more connectivity issues, especially as CGN takes effect. Could you detail more? AFAIK, traffic from a 6to4 source doesn't go across a CGN. RD >=20 >=20 > Jack >=20 From jbates@brightok.net Mon Feb 7 06:37:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF17A3A6E02 for ; Mon, 7 Feb 2011 06:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kV5bVq61WaUT for ; Mon, 7 Feb 2011 06:37:31 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id D87033A691C for ; Mon, 7 Feb 2011 06:37:30 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p17EbX4I006691; Mon, 7 Feb 2011 08:37:33 -0600 (CST) Message-ID: <4D5003AC.7020803@brightok.net> Date: Mon, 07 Feb 2011 08:37:32 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <8469C978-D60E-45AD-A534-A8E989DB8374@free.fr> <4D4FF856.6040306@brightok.net> In-Reply-To: <4D4FF856.6040306@brightok.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 14:37:31 -0000 I'm retracting my argument of 6to4 direct over anycast. See below On 2/7/2011 7:49 AM, Jack Bates wrote: >> I hope we can converge. >> This statement isn't completely right because a server having a 6to4 >> address can be unreachable in IPv4. >> Let's take a server that has both: >> - a private IPv4 address (the CPE has a NAT44) >> - a 6to4 address (the CPE has a public IPv4 address from which it >> derives a 6to4 prefix) >> This server is reachable in IPv6 at its 6to4 address, but isn't >> reachable in IPv4 because of the NAT. >> > In this particular scenario, advertising a 6to4 address increases > reachability; as it doesn't require the client to have an anycast 6to4 > relay to get to the native IPv6 address; ie, it will keep some 6to4 > clients from breaking. This would work in the short term. In the long run, advertising a 6to4 in DNS will cause more breakage. An ISP which supports a 6to4 anycast relay (which should be all of them) should have a policy as follows. - If not performing CGN on IPv4, allow the packet through untouched. The server (which should support 6to4 or have guaranteed relay that does) can send the packet back direct. - If performing CGN on IPv4, the 6to4 relay should be prior to CGN and NPTv6 should be performed on the relay. This will force the server to send the packet back to the native address where it will be translated back to the local 6to4 address. CGN is coming. The providers will be the ones who must make the 6to4 necessary changes. Servers advertising a 6to4 address in a CGN environment will break fixes that providers can deploy (if we want to call NPTv6 a fix). Jack From moore@network-heretics.com Mon Feb 7 06:35:37 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1288A3A6DF9 for ; Mon, 7 Feb 2011 06:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PADy5xZUd0W4 for ; Mon, 7 Feb 2011 06:35:36 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 1BD4B3A691C for ; Mon, 7 Feb 2011 06:35:36 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmSBm-0003sl-Pm; Mon, 07 Feb 2011 09:35:39 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D4FFF68.2000403@brightok.net> Date: Mon, 7 Feb 2011 09:35:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3AC337CC-1230-4E4B-A4D2-2E25FD832512@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94003408c3405be23664553b09feb04e9b0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 X-Mailman-Approved-At: Mon, 07 Feb 2011 06:42:02 -0800 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 14:35:37 -0000 On Feb 7, 2011, at 9:19 AM, Jack Bates wrote: > On 2/7/2011 8:07 AM, Keith Moore wrote: >> It seems to me that servers which support all of (native v6, 6to4, = v4) will be more reachable than servers which support only (native v6, = v4), because there will be v6-only hosts that sit behind 6to4 routers = (each with only an external v4 connection) and those hosts will = therefore be assigned a 6to4 address but not a native v6 address. >=20 > The problem with your client side layout is that it is very specific. >=20 > - If we are referring to a CPE, there is no reason they should not be = doing IPv4 NAT AND 6to4 Yes, but IPv4 NAT will break applications that 6to4 will not. Given the = choice between a v6 address and a NATted v4 address, the former will = often (though not always) work better. Furthermore if the CPE is = provided by an ISP, the ISP can make sure that its relay routers work. > - If we are referring to an ISP network layout, the ISP will need to = fix the network. >=20 > The argument/benefit of 6to4 over IPv4 is support for end to end = connectivity when you have a 6to4 CPE. The problem is that 6to4 often = breaks (and will break more often with CGN) more than using IPv4. That depends on what application you're running. It's not true in = general. > Advertising a 6to4 address on a server which supports IPv4 will cause = more connectivity issues, especially as CGN takes effect. you appear to be assuming that everything acts like HTTP. Keith From jbates@brightok.net Mon Feb 7 06:42:52 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48CD03A6936 for ; Mon, 7 Feb 2011 06:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyzckHJiePfF for ; Mon, 7 Feb 2011 06:42:51 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 7C3A73A68C6 for ; Mon, 7 Feb 2011 06:42:51 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p17EgrL4007997; Mon, 7 Feb 2011 08:42:53 -0600 (CST) Message-ID: <4D5004ED.2000903@brightok.net> Date: Mon, 07 Feb 2011 08:42:53 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> <96AAB522-4179-45BC-8FC3-A4EF1A7509A4@free.fr> In-Reply-To: <96AAB522-4179-45BC-8FC3-A4EF1A7509A4@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 14:42:52 -0000 On 2/7/2011 8:37 AM, Rémi Després wrote: > Could you detail more? > AFAIK, traffic from a 6to4 source doesn't go across a CGN. > 6to4 direct to 6to4 will tunnel over IPv4 and not use an ISP relay. CGN will break it. By NOT advertising 6to4 on the server, the 6to4 client is forced to use the anycast relay. The provider can then policy it with NPTv6 if the v4 address is behind CGN. Responses will be returned to the relay natively then. Jack From moore@network-heretics.com Mon Feb 7 06:48:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF2F3A691C for ; Mon, 7 Feb 2011 06:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sufrB+qdDkFW for ; Mon, 7 Feb 2011 06:48:23 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 79C1B3A68C6 for ; Mon, 7 Feb 2011 06:48:23 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmSO9-0005eE-8f; Mon, 07 Feb 2011 09:48:26 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: <4D5004ED.2000903@brightok.net> Date: Mon, 7 Feb 2011 09:48:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> <96AAB522-4179-45BC-8FC3-A4EF1A7509A4@free.fr> <4D5004ED.2000903@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940a45d13c5e4555e77f2e621aca3843379350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 14:48:24 -0000 On Feb 7, 2011, at 9:42 AM, Jack Bates wrote: > On 2/7/2011 8:37 AM, R=E9mi Despr=E9s wrote: >> Could you detail more? >> AFAIK, traffic from a 6to4 source doesn't go across a CGN. >>=20 >=20 > 6to4 direct to 6to4 will tunnel over IPv4 and not use an ISP relay. = CGN will break it. >=20 > By NOT advertising 6to4 on the server, the 6to4 client is forced to = use the anycast relay. The provider can then policy it with NPTv6 if the = v4 address is behind CGN. Responses will be returned to the relay = natively then. I keep seeing this pattern where desperate and technically dubious = measures that are employed to keep v4 working, also hamper transition to = v6. This is fundamentally broken. =20 The principle requirement that should be imposed of all v4-extension = measures is that they provide (or at least, do not inhibit) a clear = transition path to v6. Keith From martin@millnert.se Mon Feb 7 06:49:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6C63A6DD3 for ; Mon, 7 Feb 2011 06:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5hX5dKqOWqC for ; Mon, 7 Feb 2011 06:49:12 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by core3.amsl.com (Postfix) with ESMTP id 79F973A68C6 for ; Mon, 7 Feb 2011 06:49:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 006F37791; Mon, 7 Feb 2011 15:53:57 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9+TrFILO91i; Mon, 7 Feb 2011 15:53:57 +0100 (CET) Received: from [IPv6:2a02:9a0:100:2300::6] (shakira-work.us.millnert.se [IPv6:2a02:9a0:100:2300::6]) by ncis.csbnet.se (Postfix) with ESMTPSA id 8B5FF78B; Mon, 7 Feb 2011 15:53:56 +0100 (CET) From: Martin Millnert To: Tore Anderson In-Reply-To: <4D4C4C24.3070209@redpill-linpro.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> <4D4C4C24.3070209@redpill-linpro.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Feb 2011 09:49:12 -0500 Message-ID: <1297090152.26424.11.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 14:49:13 -0000 On Fri, 2011-02-04 at 19:57 +0100, Tore Anderson wrote: > Therefore, 6to4 should *not* be enabled by default in any box that > take on the role of a router - it makes the IPv6 end user experience > suck. "take on the role of a router != 6to4 relay", I assume. :) Excellent. More advice for the other draft, about suggested default values for automatic v6 tunnels on hosts? Or should it be merged into this? The above quite falls between the two atm. Regards, Martin From jbates@brightok.net Mon Feb 7 06:51:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CFE93A691C for ; Mon, 7 Feb 2011 06:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.021 X-Spam-Level: X-Spam-Status: No, score=-3.021 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoazwEGH6l3R for ; Mon, 7 Feb 2011 06:51:06 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id ABCC43A6DD3 for ; Mon, 7 Feb 2011 06:51:06 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p17Ep89F010088; Mon, 7 Feb 2011 08:51:08 -0600 (CST) Message-ID: <4D5006DB.3040209@brightok.net> Date: Mon, 07 Feb 2011 08:51:07 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> <3AC337CC-1230-4E4B-A4D2-2E25FD832512@network-heretics.com> In-Reply-To: <3AC337CC-1230-4E4B-A4D2-2E25FD832512@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 14:51:08 -0000 On 2/7/2011 8:35 AM, Keith Moore wrote: > Yes, but IPv4 NAT will break applications that 6to4 will not. Given > the choice between a v6 address and a NATted v4 address, the former > will often (though not always) work better. Furthermore if the CPE > is provided by an ISP, the ISP can make sure that its relay routers > work. > I agree, if CGN wasn't going to exist. However, it will be, and I see direct 6to4 breaking. The way around this is for 6to4 to be properly supported by the ISP (see my other responses) > That depends on what application you're running. It's not true in > general. > It's not true in general, yet 6to4 is breaking and one of the reasons for this draft. With CGN, I expect 6to4 to break even more as it is not NAT friendly. However, NPTv6 at a multicast relay will work perfectly fine (though probably isn't much better than CGN on the v4). Unfortunately, relays aren't used if 6to4 is advertised. >> Advertising a 6to4 address on a server which supports IPv4 will >> cause more connectivity issues, especially as CGN takes effect. > > you appear to be assuming that everything acts like HTTP. > I'm presuming that CGN will exist and NAT break 6to4. The workarounds for basic connectivity for an ISP is to use the ISP relays, but those relays only take effect if 6to4 isn't advertised by the server. There will be a degree of application breakage in an ISP provided NAT scenario. 6to4 only connectivity will take the worst of it. 6rd is definitely recommended over 6to4 as it doesn't require the NPTv6 on the relay when NAT44 is in effect and is guaranteed to use the ISP relays. Jack From jbates@brightok.net Mon Feb 7 06:57:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCB123A6A73 for ; Mon, 7 Feb 2011 06:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.062 X-Spam-Level: X-Spam-Status: No, score=-3.062 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJ-sbXIMnkGE for ; Mon, 7 Feb 2011 06:57:10 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id BF4FC3A6D7D for ; Mon, 7 Feb 2011 06:57:05 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17Ev6YK013341; Mon, 7 Feb 2011 08:57:06 -0600 (CST) Message-ID: <4D500842.1060109@brightok.net> Date: Mon, 07 Feb 2011 08:57:06 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> <96AAB522-4179-45BC-8FC3-A4EF1A7509A4@free.fr> <4D5004ED.2000903@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 14:57:11 -0000 On 2/7/2011 8:48 AM, Keith Moore wrote: > I keep seeing this pattern where desperate and technically dubious > measures that are employed to keep v4 working, also hamper transition > to v6. This is fundamentally broken. > If we are not keeping v4 working, then 6to4 should never be used, as there shouldn't be IPv4 connectivity to use it. It is a transition technology (and the worst of them, though the most common activated). A dual stack server should use IPv4 for it's connectivity over 6to4 direct. An IPv6 only server should not encourage a client to try and reach it direct via 6to4 (let the client anycast so ISP workarounds will allow the communication). > The principle requirement that should be imposed of all v4-extension > measures is that they provide (or at least, do not inhibit) a clear > transition path to v6. > That is what we are discussing. A fundamental flaw of 6to4 is that if the address is advertised in DNS and the client tries to connect directly, any NAT in the middle will break it. By not advertising a 6to4 address, the client will either use anycast 6to4 relays where ISPs can NPTv6 to deal with the NAT or use IPv4 direct which is at least acceptable. Jack From martin@millnert.se Mon Feb 7 07:06:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EDC63A691C for ; Mon, 7 Feb 2011 07:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5DI1tvRm1lL for ; Mon, 7 Feb 2011 07:06:56 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by core3.amsl.com (Postfix) with ESMTP id D098D3A6D03 for ; Mon, 7 Feb 2011 07:06:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id E2A417791; Mon, 7 Feb 2011 16:11:41 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dp-AjP7mDS0y; Mon, 7 Feb 2011 16:11:41 +0100 (CET) Received: from [IPv6:2a02:9a0:100:2300::6] (shakira-work.us.millnert.se [IPv6:2a02:9a0:100:2300::6]) by ncis.csbnet.se (Postfix) with ESMTPSA id 1ABD378B; Mon, 7 Feb 2011 16:11:39 +0100 (CET) From: Martin Millnert To: Keith Moore In-Reply-To: <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Feb 2011 10:06:55 -0500 Message-ID: <1297091215.26424.13.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:06:57 -0000 On Mon, 2011-02-07 at 09:07 -0500, Keith Moore wrote: > It seems to me that servers which support all of (native v6, 6to4, v4) > will be more reachable than servers which support only (native v6, > v4), because there will be v6-only hosts that sit behind 6to4 routers > (each with only an external v4 connection) and those hosts will > therefore be assigned a 6to4 address but not a native v6 address. A very favorable configuration here could be the following: A ("content") server that has native v6 and v4 will benefit from sending IPv6-in-IPv4 packets back for connections arriving from 2002::/16. Adding some additional application layer glue/clue here, a host with native IPv6 and IPv4 can consider arriving 6to4-packets to be plain IPv4 when the connection is handed off to the application layer (for those that roll their own...), with clearly added benefits to the already IPv4-aware application layer. (I've heard "But I don't want to run a 6to4 interface on my servers" more than once, so, this way you don't have to). As far as I can see this should be the way forward for "content servers", which could go a long way of dealing with poor 6to4-relays in the reverse path by simply ignoring them, and the 6to4 problem becomes mostly a one-way problem: operator -> content provider, which this draft addresses. It furthermore enables operators to, for any content provider using this method, to be in control of the 6to4 relay they use themselves. Content providers are clearly interested in minimizing the pain 6to4 causes. A draft covering the above, in addition to this pain-minimizing draft for operators, could work together to make the problem smaller over time, which must be good. Regards, Martin From moore@network-heretics.com Mon Feb 7 07:07:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39CDE3A6D7D for ; Mon, 7 Feb 2011 07:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmhqzUOK+rmO for ; Mon, 7 Feb 2011 07:07:35 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 563463A6A73 for ; Mon, 7 Feb 2011 07:07:35 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmSgj-0006Ko-Tq; Mon, 07 Feb 2011 10:07:38 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D5006DB.3040209@brightok.net> Date: Mon, 7 Feb 2011 10:07:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0EA7E738-697C-4AC9-91CD-682BCC8D7FFE@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> <3AC337CC-1230-4E4B-A4D2-2E25FD832512@network-heretics.com> <4D5006DB.3040209@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9402b525b8c3dbeab8d4b2653d068781eb7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:07:36 -0000 On Feb 7, 2011, at 9:51 AM, Jack Bates wrote: > On 2/7/2011 8:35 AM, Keith Moore wrote: >> Yes, but IPv4 NAT will break applications that 6to4 will not. Given >> the choice between a v6 address and a NATted v4 address, the former >> will often (though not always) work better. Furthermore if the CPE >> is provided by an ISP, the ISP can make sure that its relay routers >> work. >>=20 >=20 > I agree, if CGN wasn't going to exist. However, it will be, and I see = direct 6to4 breaking. The way around this is for 6to4 to be properly = supported by the ISP (see my other responses) maybe the way around it is for all ISPs that implement CGN to also = implement native v6 via some means. the people that cause breakage need = to assume some responsibility for fixing the breakage. =20 >> That depends on what application you're running. It's not true in >> general. >>=20 >=20 > It's not true in general, yet 6to4 is breaking and one of the reasons = for this draft. With CGN, I expect 6to4 to break even more as it is not = NAT friendly. However, NPTv6 at a multicast relay will work perfectly = fine (though probably isn't much better than CGN on the v4). >=20 > Unfortunately, relays aren't used if 6to4 is advertised. if CGN breaks 6to4 then that should be mentioned in the advisory = document... I don't have time to look right now to be sure, but I don't = recall that it was mentioned. Keith From tore.anderson@redpill-linpro.com Mon Feb 7 07:11:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FDC3A6D7D for ; Mon, 7 Feb 2011 07:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCroW-i0bZhp for ; Mon, 7 Feb 2011 07:11:49 -0800 (PST) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id E15133A68C6 for ; Mon, 7 Feb 2011 07:11:48 -0800 (PST) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id AD370C403A; Mon, 7 Feb 2011 16:11:52 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mailhub.linpro.no Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id Bd2bJwIJNvtB; Mon, 7 Feb 2011 16:11:45 +0100 (CET) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Mon, 7 Feb 2011 16:11:45 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 24C75170C00C; Mon, 7 Feb 2011 16:11:45 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK2nkmTmI54N; Mon, 7 Feb 2011 16:11:44 +0100 (CET) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id B7356170C00B; Mon, 7 Feb 2011 16:11:44 +0100 (CET) Message-ID: <4D500BB0.70103@redpill-linpro.com> Date: Mon, 07 Feb 2011 16:11:44 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <8469C978-D60E-45AD-A534-A8E989DB8374@free.fr> In-Reply-To: <8469C978-D60E-45AD-A534-A8E989DB8374@free.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:11:50 -0000 * Rémi Després > Thus, a server that advertises a native IPv6 address AND an 6to4 > address becomes reachable by 6to4 clients even if they have no access > to 6to4 relays. > Reachability is thus increased, and I haven't found any adverse > effect. > Do you see any? I actually attempted this a while back. It was a disaster and the brokenness percentage skyrocketed. I don't think any content providers in their right mind will publish AAAA-records for a 2002::/16 address. Aben and Huston have both measured a 6to4 fail rate of around 15% - and that is with relays working fine in both directions! As long as nobody's using 6to4 except as a last resort, it's not a problem, but the instant you publish 6to4 AAAAs, you will attract traffic from millions of hosts in networks that filter proto-41. Regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From moore@network-heretics.com Mon Feb 7 07:14:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11AB3A6D8C for ; Mon, 7 Feb 2011 07:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PgI2LuMn-iO for ; Mon, 7 Feb 2011 07:14:03 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id B29FE3A6D7D for ; Mon, 7 Feb 2011 07:14:03 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmSn0-0004DK-PF; Mon, 07 Feb 2011 10:14:07 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <1297091215.26424.13.camel@shakira.millnert.se> Date: Mon, 7 Feb 2011 10:14:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <1297091215.26424.13.camel@shakira.millnert.se> To: Martin Millnert X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9404f2b4161ed32edd3586092f00242f9bd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:14:04 -0000 On Feb 7, 2011, at 10:06 AM, Martin Millnert wrote: > On Mon, 2011-02-07 at 09:07 -0500, Keith Moore wrote: >> It seems to me that servers which support all of (native v6, 6to4, = v4) >> will be more reachable than servers which support only (native v6, >> v4), because there will be v6-only hosts that sit behind 6to4 routers >> (each with only an external v4 connection) and those hosts will >> therefore be assigned a 6to4 address but not a native v6 address. =20 >=20 > A very favorable configuration here could be the following: > A ("content") server that has native v6 and v4 will benefit from > sending IPv6-in-IPv4 packets back for connections arriving from > 2002::/16. > Adding some additional application layer glue/clue here, a host with > native IPv6 and IPv4 can consider arriving 6to4-packets to be plain = IPv4 > when the connection is handed off to the application layer (for those > that roll their own...), with clearly added benefits to the already > IPv4-aware application layer.=20 I can't imagine an interpretation of this that makes any sense at all. = what in the world do you mean? Keith From tore.anderson@redpill-linpro.com Mon Feb 7 07:17:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A2DA3A6DF4 for ; Mon, 7 Feb 2011 07:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Uq2s-fIX9PA for ; Mon, 7 Feb 2011 07:17:16 -0800 (PST) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id 8C6D63A6DE5 for ; Mon, 7 Feb 2011 07:17:16 -0800 (PST) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 733FFC409A; Mon, 7 Feb 2011 16:17:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mailhub.linpro.no Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id wuFBrkjygxuz; Mon, 7 Feb 2011 16:17:11 +0100 (CET) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Mon, 7 Feb 2011 16:17:11 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id C32E4170C00A; Mon, 7 Feb 2011 16:17:11 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28mH8tVQp0F9; Mon, 7 Feb 2011 16:17:11 +0100 (CET) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 691EC170C00C; Mon, 7 Feb 2011 16:17:11 +0100 (CET) Message-ID: <4D500CF7.70601@redpill-linpro.com> Date: Mon, 07 Feb 2011 16:17:11 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Martin Millnert References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> <4D4C4C24.3070209@redpill-linpro.com> <1297090152.26424.11.camel@shakira.millnert.se> In-Reply-To: <1297090152.26424.11.camel@shakira.millnert.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:17:17 -0000 * Martin Millnert > On Fri, 2011-02-04 at 19:57 +0100, Tore Anderson wrote: >> Therefore, 6to4 should *not* be enabled by default in any box that >> take on the role of a router - it makes the IPv6 end user experience >> suck. > > "take on the role of a router != 6to4 relay", I assume. :) No, that's what I meant. Anything that operates as a router, like a CPE, home gateway, wireless access point, end-user OS with «turn your box into a router»-type of functionality (e.g. Windows ICS), and so on, should *not* have 6to4 relay functionality enabled by default. The only place where 6to4 causes little damage is when terminated on an end host that doesn't share the 6to4 connectivity in any way, provided that the host in question also have RFC 3484-compliant system resolvers or de-prefers 6to4 another way. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From ichiroumakino@gmail.com Mon Feb 7 07:17:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B22C3A6E15 for ; Mon, 7 Feb 2011 07:17:48 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PssqsqETDboX for ; Mon, 7 Feb 2011 07:17:48 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id CFCD63A6E13 for ; Mon, 7 Feb 2011 07:17:47 -0800 (PST) Received: by eyd10 with SMTP id 10so2553138eyd.31 for ; Mon, 07 Feb 2011 07:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:from:content-type :content-transfer-encoding:subject:date:references:to:message-id :mime-version:x-mailer; bh=TFsGHWv2Tw4Q7lecX2qO7PMHsajH6ifvyNuzVEYHxkw=; b=EYZeKfKEY/Kox3IuISW1bEzYAWhzvztcTk7iEbjrvf5cPzNsVBbarvY/7SXrd0WtZx NurxX8A+cXJCtroxERE2Q7BfELaF7VLPCzp2bizE2ELCeDZpc24QXE2feaGbVwbAYbS5 BM+OXNluQ0SMg6SQ8zLaA+gQEAJKNcGDfAxZU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :references:to:message-id:mime-version:x-mailer; b=rqMLC1zkM6hKWfHOkH9Hm0oj6iuPVcYKxALiimQpWGweY6FHn33UrT3b+mWYItWDOo B1G1j8Em7zmOO+rRu045cuK56j9R6u2qCwC6Ivtz1oWFCwgsaCiqLw25tK1c7ezFiRo4 B675/qklrtKkp8m1J0kxvg3PomZPxpiweWApo= Received: by 10.14.17.193 with SMTP id j41mr5364454eej.38.1297091871354; Mon, 07 Feb 2011 07:17:51 -0800 (PST) Received: from dhcp-10-55-82-142.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id q52sm3189434eei.21.2011.02.07.07.17.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 07:17:50 -0800 (PST) Sender: Ole Troan From: Ole Troan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Feb 2011 16:17:48 +0100 References: <20110207151430.44A393A6DD8@core3.amsl.com> To: IPv6 Operations Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:17:48 -0000 I just posted the following draft suggesting that we move the 6to4 = documents to historic. cheers, Ole Begin forwarded message: > From: IETF I-D Submission Tool > Date: February 7, 2011 16:14:30 GMT+01:00 > To: ot@cisco.com > Subject: New Version Notification for = draft-troan-v6ops-6to4-to-historic-00=20 >=20 >=20 > A new version of I-D, draft-troan-v6ops-6to4-to-historic-00.txt has = been successfully submitted by Ole Troan and posted to the IETF = repository. >=20 > Filename: draft-troan-v6ops-6to4-to-historic > Revision: 00 > Title: Request to move Connection of IPv6 Domains via = IPv4 Clouds (6to4) to Historic status > Creation_date: 2011-02-07 > WG ID: Independent Submission > Number_of_pages: 11 >=20 > 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 [RFC3056] is moved to historic status. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 From moore@network-heretics.com Mon Feb 7 07:18:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735FE3A6E1E for ; Mon, 7 Feb 2011 07:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ex2A+MM75XL for ; Mon, 7 Feb 2011 07:18:21 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 8BF803A6E17 for ; Mon, 7 Feb 2011 07:18:21 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmSrB-00069C-EH; Mon, 07 Feb 2011 10:18:26 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D500842.1060109@brightok.net> Date: Mon, 7 Feb 2011 10:18:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <815713DD-9404-40D7-AC5D-7E02AD903A73@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> <96AAB522-4179-45BC-8FC3-A4EF1A7509A4@free.fr> <4D5004ED.2000903@brightok.net> <4D500842.1060109@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940d56ebdac614bc0f4f9fe02182e2d7c0a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:18:22 -0000 On Feb 7, 2011, at 9:57 AM, Jack Bates wrote: > On 2/7/2011 8:48 AM, Keith Moore wrote: >> I keep seeing this pattern where desperate and technically dubious >> measures that are employed to keep v4 working, also hamper transition >> to v6. This is fundamentally broken. >>=20 >=20 > If we are not keeping v4 working, then 6to4 should never be used, as = there shouldn't be IPv4 connectivity to use it. It is a transition = technology (and the worst of them, though the most common activated). A = dual stack server should use IPv4 for it's connectivity over 6to4 = direct. An IPv6 only server should not encourage a client to try and = reach it direct via 6to4 (let the client anycast so ISP workarounds will = allow the communication). >=20 >> The principle requirement that should be imposed of all v4-extension >> measures is that they provide (or at least, do not inhibit) a clear >> transition path to v6. >>=20 >=20 > That is what we are discussing. A fundamental flaw of 6to4 is that if = the address is advertised in DNS and the client tries to connect = directly, any NAT in the middle will break it. That is not a flaw with 6to4, it's a flaw with the idea that you can put = NATs in the middle of the network. =20 Keith From martin@millnert.se Mon Feb 7 07:29:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1035B3A6941 for ; Mon, 7 Feb 2011 07:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKXdx4NbBupg for ; Mon, 7 Feb 2011 07:29:33 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by core3.amsl.com (Postfix) with ESMTP id 2E6F53A68C6 for ; Mon, 7 Feb 2011 07:29:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 3664C7791; Mon, 7 Feb 2011 16:34:19 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id melK9Tx+CMzp; Mon, 7 Feb 2011 16:34:19 +0100 (CET) Received: from [IPv6:2a02:9a0:100:2300::6] (shakira-work.us.millnert.se [IPv6:2a02:9a0:100:2300::6]) by ncis.csbnet.se (Postfix) with ESMTPSA id 5148D78B; Mon, 7 Feb 2011 16:34:17 +0100 (CET) From: Martin Millnert To: Tore Anderson In-Reply-To: <4D500CF7.70601@redpill-linpro.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> <4D4C4C24.3070209@redpill-linpro.com> <1297090152.26424.11.camel@shakira.millnert.se> <4D500CF7.70601@redpill-linpro.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Feb 2011 10:29:32 -0500 Message-ID: <1297092572.26424.27.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:29:34 -0000 On Mon, 2011-02-07 at 16:17 +0100, Tore Anderson wrote: > * Martin Millnert > > "take on the role of a router != 6to4 relay", I assume. :) > > No, that's what I meant. Anything that operates as a router, like a CPE, > home gateway, wireless access point, end-user OS with «turn your box > into a router»-type of functionality (e.g. Windows ICS), and so on, > should *not* have 6to4 relay functionality enabled by default. Right, I need to further quality my '6to4 relay'. I meant 6to4 relay as ISP operated relays. They quite necessarily need to have "6to4 enabled". :) Regards, -- Martin Millnert From jbates@brightok.net Mon Feb 7 07:32:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0423A6DD5 for ; Mon, 7 Feb 2011 07:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.091 X-Spam-Level: X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldXvoTJftLv2 for ; Mon, 7 Feb 2011 07:32:41 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id EB2D83A6D90 for ; Mon, 7 Feb 2011 07:32:40 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p17FWjBu021076; Mon, 7 Feb 2011 09:32:45 -0600 (CST) Message-ID: <4D50109C.4080306@brightok.net> Date: Mon, 07 Feb 2011 09:32:44 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <4D4A2401.2020500@gmail.com> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> <96AAB522-4179-45BC-8FC3-A4EF1A7509A4@free.fr> <4D5004ED.2000903@brightok.net> <4D500842.1060109@brightok.net> <815713DD-9404-40D7-AC5D-7E02AD903A73@network-heretics.com> In-Reply-To: <815713DD-9404-40D7-AC5D-7E02AD903A73@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:32:41 -0000 On 2/7/2011 9:18 AM, Keith Moore wrote: > That is not a flaw with 6to4, it's a flaw with the idea that you can put NATs in the middle of the network. Then give the ISPs more IPv4 space, please. NAT in the middle will happen with IPv4. Guaranteed. The more native IPv6 traffic there is, the more IPv4 will be broken. Connectivity will be broken worse than it is. Anyone who depends on 6to4 as a transition technology is asking for problems. It CAN work somewhat if the ISP relays are used, though in a CGN environment, the relay will have to use NPTv6, which will also break IPv6 as much as IPv4 CGN. However, some connectivity is better than none. All ISPs are recommended to deploy native (direct or tunneled), 6rd, or any transition mechanism other than 6to4. Advertising 6to4 via AAAA is likely to break connectivity to your server. Jack From tore.anderson@redpill-linpro.com Mon Feb 7 07:34:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29173A6E0E for ; Mon, 7 Feb 2011 07:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qANmqHEad7p for ; Mon, 7 Feb 2011 07:34:41 -0800 (PST) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id 777FE3A68C6 for ; Mon, 7 Feb 2011 07:34:41 -0800 (PST) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 693F7C409D; Mon, 7 Feb 2011 16:34:45 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mailhub.linpro.no Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id ejMbIkMR+GJY; Mon, 7 Feb 2011 16:34:37 +0100 (CET) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Mon, 7 Feb 2011 16:34:37 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id C11B5170C00D; Mon, 7 Feb 2011 16:34:37 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBTao1TjhQhD; Mon, 7 Feb 2011 16:34:37 +0100 (CET) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 59BA9170C00B; Mon, 7 Feb 2011 16:34:37 +0100 (CET) Message-ID: <4D50110D.5080709@redpill-linpro.com> Date: Mon, 07 Feb 2011 16:34:37 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Martin Millnert References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> <4D4C4C24.3070209@redpill-linpro.com> <1297090152.26424.11.camel@shakira.millnert.se> <4D500CF7.70601@redpill-linpro.com> <1297092572.26424.27.camel@shakira.millnert.se> In-Reply-To: <1297092572.26424.27.camel@shakira.millnert.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:34:42 -0000 * Martin Millnert > Right, I need to further quality my '6to4 relay'. I meant 6to4 relay as > ISP operated relays. They quite necessarily need to have "6to4 > enabled". :) My main gripe is the «by default» bit. I'd be equally upset if C or J or any other ISP-grade router vendor started announcing 2002::/16 or 192.88.99.1/24 into the DFZ without the network admin first needing to explicitly configure it... :-) Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From jbates@brightok.net Mon Feb 7 07:34:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D0B3A6E17 for ; Mon, 7 Feb 2011 07:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.112 X-Spam-Level: X-Spam-Status: No, score=-3.112 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3KDmDkOj9-c for ; Mon, 7 Feb 2011 07:34:49 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 6375A3A6E07 for ; Mon, 7 Feb 2011 07:34:49 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17FYplS022911; Mon, 7 Feb 2011 09:34:51 -0600 (CST) Message-ID: <4D50111B.3050109@brightok.net> Date: Mon, 07 Feb 2011 09:34:51 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> <3AC337CC-1230-4E4B-A4D2-2E25FD832512@network-heretics.com> <4D5006DB.3040209@brightok.net> <0EA7E738-697C-4AC9-91CD-682BCC8D7FFE@network-heretics.com> In-Reply-To: <0EA7E738-697C-4AC9-91CD-682BCC8D7FFE@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:34:50 -0000 On 2/7/2011 9:07 AM, Keith Moore wrote: > > maybe the way around it is for all ISPs that implement CGN to also > implement native v6 via some means. the people that cause breakage > need to assume some responsibility for fixing the breakage. > 6to4 is the transition protocol of least resort. If it's being used, things are already in bad shape. Advertising 6to4 is asking for breakage. > if CGN breaks 6to4 then that should be mentioned in the advisory > document... I don't have time to look right now to be sure, but I > don't recall that it was mentioned. There is no IF. CGN breaks 6to4. It is NAT. 6to4 doesn't work through NAT. I'm not even sure an ALG could fix this as there's no reserved bits for the ALG to determine which IPv4 customer to send to, thus there would have to be some type of v6 NAT state involved. Jack From moore@network-heretics.com Mon Feb 7 07:37:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938323A6937 for ; Mon, 7 Feb 2011 07:37:42 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXSFZbQdaQy7 for ; Mon, 7 Feb 2011 07:37:41 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 9E60F3A6925 for ; Mon, 7 Feb 2011 07:37:41 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmT9t-00006b-7C; Mon, 07 Feb 2011 10:37:45 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D50109C.4080306@brightok.net> Date: Mon, 7 Feb 2011 10:37:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4A2401.2020500@gmail.com> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> <96AAB522-4179-45BC-8FC3-A4EF1A7509A4@free.fr> <4D5004ED.2000903@brightok.net> <4D500842.1060109@brightok.net> <815713DD-9404-40D7-AC5D-7E02AD903A73@network-heretics.com> <4D5010 9C.4080306@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940afb09bd1351d1c50b62e14b792870d5f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:37:42 -0000 > On 2/7/2011 9:18 AM, Keith Moore wrote: >> That is not a flaw with 6to4, it's a flaw with the idea that you can = put NATs in the middle of the network. >=20 > Then give the ISPs more IPv4 space, please. NAT in the middle will = happen with IPv4. Guaranteed. The more native IPv6 traffic there is, the = more IPv4 will be broken. >=20 > Connectivity will be broken worse than it is. Anyone who depends on = 6to4 as a transition technology is asking for problems. It CAN work = somewhat if the ISP relays are used, though in a CGN environment, the = relay will have to use NPTv6, which will also break IPv6 as much as IPv4 = CGN. However, some connectivity is better than none. >=20 > All ISPs are recommended to deploy native (direct or tunneled), 6rd, = or any transition mechanism other than 6to4. Advertising 6to4 via AAAA = is likely to break connectivity to your server. I get what you are saying. What I'm saying is that IETF cannot afford = to keep looking at these mechanisms in isolation from one another. Nor = can it afford to endorse mechanisms that extend the life of v4 at the = expense of mechanisms that enable transition to v6. Keith From martin@millnert.se Mon Feb 7 07:40:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA2B3A6925 for ; Mon, 7 Feb 2011 07:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCNUD6NX+7eW for ; Mon, 7 Feb 2011 07:40:17 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by core3.amsl.com (Postfix) with ESMTP id 541843A6E0F for ; Mon, 7 Feb 2011 07:39:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id A290A7791; Mon, 7 Feb 2011 16:44:22 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BNrkMt8+mpl; Mon, 7 Feb 2011 16:44:22 +0100 (CET) Received: from [IPv6:2a02:9a0:100:2300::6] (shakira-work.us.millnert.se [IPv6:2a02:9a0:100:2300::6]) by ncis.csbnet.se (Postfix) with ESMTPSA id 2CF8978B; Mon, 7 Feb 2011 16:44:20 +0100 (CET) From: Martin Millnert To: Keith Moore In-Reply-To: References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <1297091215.26424.13.camel@shakira.millnert.se> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Feb 2011 10:39:36 -0500 Message-ID: <1297093176.26424.28.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:40:17 -0000 On Mon, 2011-02-07 at 10:14 -0500, Keith Moore wrote: > On Feb 7, 2011, at 10:06 AM, Martin Millnert wrote: > > > On Mon, 2011-02-07 at 09:07 -0500, Keith Moore wrote: > >> It seems to me that servers which support all of (native v6, 6to4, v4) > >> will be more reachable than servers which support only (native v6, > >> v4), because there will be v6-only hosts that sit behind 6to4 routers > >> (each with only an external v4 connection) and those hosts will > >> therefore be assigned a 6to4 address but not a native v6 address. > > > > A very favorable configuration here could be the following: > > A ("content") server that has native v6 and v4 will benefit from > > sending IPv6-in-IPv4 packets back for connections arriving from > > 2002::/16. > > Adding some additional application layer glue/clue here, a host with > > native IPv6 and IPv4 can consider arriving 6to4-packets to be plain IPv4 > > when the connection is handed off to the application layer (for those > > that roll their own...), with clearly added benefits to the already > > IPv4-aware application layer. > > I can't imagine an interpretation of this that makes any sense at all. what in the world do you mean? > > Keith Sorry Keith, I'll try again. First, I was just agreeing that a content server should not send packets towards 6to4 anycast space. Then, I tried to explain a possible implementation method for a dual-stacked content server: 1) A content server has native IPv6 and IPv4, eg is dual-stacked. 2) A TCP SYN arrives on its IPv6 interface from 2002::/16 space. 3) Return packets are sent as IPv6-over-IPv4 to the unicast address (Brian did note some brokenness here; perhaps it can be helped by using source address 192.88.99.1?) 4) When the connection is delivered to the application layer, it is converted into a IPv4 connection, by decoding the IPv4 address that is encoded in 2002::/16 as the source address. 5) From now on, it's just IPv4 for the applications which they should be fairly familiar with. Did this make more sense? Regards, Martin From jbates@brightok.net Mon Feb 7 07:40:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A903E3A6DE0 for ; Mon, 7 Feb 2011 07:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.129 X-Spam-Level: X-Spam-Status: No, score=-3.129 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGi+3PWQxzHt for ; Mon, 7 Feb 2011 07:40:48 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id DB96F3A6937 for ; Mon, 7 Feb 2011 07:40:47 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17Feph7024549; Mon, 7 Feb 2011 09:40:51 -0600 (CST) Message-ID: <4D501283.6050007@brightok.net> Date: Mon, 07 Feb 2011 09:40:51 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tore Anderson References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> <4D4C4C24.3070209@redpill-linpro.com> <1297090152.26424.11.camel@shakira.millnert.se> <4D500CF7.70601@redpill-linpro.com> <1297092572.26424.27.camel@shakira.millnert.se> <4D50110D.5080709@redpill-linpro.com> In-Reply-To: <4D50110D.5080709@redpill-linpro.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:40:48 -0000 On 2/7/2011 9:34 AM, Tore Anderson wrote: > My main gripe is the «by default» bit. I'd be equally upset if C or J or > any other ISP-grade router vendor started announcing 2002::/16 or > 192.88.99.1/24 into the DFZ without the network admin first needing to > explicitly configure it...:-) > I believe the presumption is that if there is no connectivity other than 6to4, might as well activate the 6to4 to reach anything not IPv4. A quick look on my windows box shows no 2002::/16 addressing; only native (presumably to keep 2002::/16 advertised networks from taking precedence over native IPv6 advertised networks via address selection algorithm. 6to4 should never be active when another IPv6 address is available. It also should never be used unless IPv6 is the only available mechanism. This is why I'm strongly against anyone ever advertising 2002::/16 in DNS. Jack From moore@network-heretics.com Mon Feb 7 07:45:30 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5FC53A6E05 for ; Mon, 7 Feb 2011 07:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIxx5FhFl8YV for ; Mon, 7 Feb 2011 07:45:30 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 05B963A6DD5 for ; Mon, 7 Feb 2011 07:45:30 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmTHQ-0003WP-NH; Mon, 07 Feb 2011 10:45:33 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D50111B.3050109@brightok.net> Date: Mon, 7 Feb 2011 10:45:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <92A4D71D-9680-4AA2-BC62-1CB0946FE86E@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> <3AC337CC-1230-4E4B-A4D2-2E25FD832512@network-heretics.com> <4D5006DB.3040209@brightok.net> <0EA7E738-697C-4AC9-91CD-682BCC8D7FFE@network-heretics.com> <4D50111B.3050109@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940ed0e834d0de29b0e1adba503495b22e6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:45:30 -0000 On Feb 7, 2011, at 10:34 AM, Jack Bates wrote: > On 2/7/2011 9:07 AM, Keith Moore wrote: >>=20 >> maybe the way around it is for all ISPs that implement CGN to also >> implement native v6 via some means. the people that cause breakage >> need to assume some responsibility for fixing the breakage. >>=20 >=20 > 6to4 is the transition protocol of least resort. If it's being used, = things are already in bad shape. Advertising 6to4 is asking for = breakage. the breakage is being caused elsewhere; 6to4 is just one of many things = that suffer from it. it's fine to point out that CGN breaks 6to4. that's another reason = that CGN should be discouraged, or at least, not deployed except along = with a mechanism for carriage of native v6. Keith From moore@network-heretics.com Mon Feb 7 07:48:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D3D3A6D97 for ; Mon, 7 Feb 2011 07:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfjEn4iM9aDv for ; Mon, 7 Feb 2011 07:48:42 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 42CCE3A6DD5 for ; Mon, 7 Feb 2011 07:48:42 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmTKX-0003KM-9Y; Mon, 07 Feb 2011 10:48:46 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <1297093176.26424.28.camel@shakira.millnert.se> Date: Mon, 7 Feb 2011 10:48:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <1297091215.26424.13.camel@shakira.millnert.se> <1297093176.26424.28.camel@shakira.millnert.se> To: Martin Millnert X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940537926bd7798bae541badc90871c55ae350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:48:43 -0000 On Feb 7, 2011, at 10:39 AM, Martin Millnert wrote: > On Mon, 2011-02-07 at 10:14 -0500, Keith Moore wrote: >> On Feb 7, 2011, at 10:06 AM, Martin Millnert wrote: >>=20 >>> On Mon, 2011-02-07 at 09:07 -0500, Keith Moore wrote: >>>> It seems to me that servers which support all of (native v6, 6to4, = v4) >>>> will be more reachable than servers which support only (native v6, >>>> v4), because there will be v6-only hosts that sit behind 6to4 = routers >>>> (each with only an external v4 connection) and those hosts will >>>> therefore be assigned a 6to4 address but not a native v6 address. =20= >>>=20 >>> A very favorable configuration here could be the following: >>> A ("content") server that has native v6 and v4 will benefit from >>> sending IPv6-in-IPv4 packets back for connections arriving from >>> 2002::/16. >>> Adding some additional application layer glue/clue here, a host with >>> native IPv6 and IPv4 can consider arriving 6to4-packets to be plain = IPv4 >>> when the connection is handed off to the application layer (for = those >>> that roll their own...), with clearly added benefits to the already >>> IPv4-aware application layer.=20 >>=20 >> I can't imagine an interpretation of this that makes any sense at = all. what in the world do you mean? >>=20 >> Keith >=20 > Sorry Keith, I'll try again. >=20 > First, I was just agreeing that a content server should not send = packets > towards 6to4 anycast space. >=20 > Then, I tried to explain a possible implementation method for a > dual-stacked content server: >=20 > 1) A content server has native IPv6 and IPv4, eg is dual-stacked. > 2) A TCP SYN arrives on its IPv6 interface from 2002::/16 space. > 3) Return packets are sent as IPv6-over-IPv4 to the unicast address > (Brian did note some brokenness here; perhaps it can be helped by = using > source address 192.88.99.1?) > 4) When the connection is delivered to the application layer, it is > converted into a IPv4 connection, by decoding the IPv4 address that is > encoded in 2002::/16 as the source address. > 5) =46rom now on, it's just IPv4 for the applications which they = should > be fairly familiar with. >=20 > Did this make more sense? no. it makes no sense at all to convert a 6to4 connection into an ipv4 = connection. Keith From moore@network-heretics.com Mon Feb 7 07:52:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779773A6D83 for ; Mon, 7 Feb 2011 07:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lu0Qrlffmo3 for ; Mon, 7 Feb 2011 07:52:31 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id EE95F3A6937 for ; Mon, 7 Feb 2011 07:52:30 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmTOB-0002iB-SW; Mon, 07 Feb 2011 10:52:32 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: <4D501283.6050007@brightok.net> Date: Mon, 7 Feb 2011 10:52:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3EC4E310-B4BC-4861-BD71-ADACF0E49664@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> <4D4C4C24.3070209@redpill-linpro.com> <1297090152.26424.11.camel@shakira.millnert.se> <4D500CF7.70601@redpill-linpro.com> <1297092572.26424.27.camel@shakira.millnert.se> <4D50110D.5080709@redpill-linpro.com> <4D501283.6050007@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940e18930f07d3918a252efc8bc1de36705350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:52:34 -0000 On Feb 7, 2011, at 10:40 AM, Jack Bates wrote: > On 2/7/2011 9:34 AM, Tore Anderson wrote: >> My main gripe is the =ABby default=BB bit. I'd be equally upset if C = or J or >> any other ISP-grade router vendor started announcing 2002::/16 or >> 192.88.99.1/24 into the DFZ without the network admin first needing = to >> explicitly configure it...:-) >>=20 >=20 > I believe the presumption is that if there is no connectivity other = than 6to4, might as well activate the 6to4 to reach anything not IPv4. >=20 > A quick look on my windows box shows no 2002::/16 addressing; only = native (presumably to keep 2002::/16 advertised networks from taking = precedence over native IPv6 advertised networks via address selection = algorithm. >=20 > 6to4 should never be active when another IPv6 address is available. It = also should never be used unless IPv6 is the only available mechanism. = This is why I'm strongly against anyone ever advertising 2002::/16 in = DNS. I do this all the time, and it generally works well. Of course one of = the reasons that I do this is because I don't have enough IPv4 addresses = to assign to all of my hosts. That's not to say that I've never seen the problems mentioned in Brian's = draft - I'm pretty sure I've seen most of those crop up also. But in = general they have not been a problem for me. So I think your recommendation against ever advertising a 2002 address = in DNS is overbroad. =20 And I find it completely unacceptable to use CGN as an excuse to = discourage use of 6to4. Keith From jbates@brightok.net Mon Feb 7 08:09:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D733A6E02 for ; Mon, 7 Feb 2011 08:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.143 X-Spam-Level: X-Spam-Status: No, score=-3.143 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIFOYKTL4cPi for ; Mon, 7 Feb 2011 08:09:44 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 7F99B3A6DD9 for ; Mon, 7 Feb 2011 08:09:44 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17G9l8x002324; Mon, 7 Feb 2011 10:09:48 -0600 (CST) Message-ID: <4D50194B.4030500@brightok.net> Date: Mon, 07 Feb 2011 10:09:47 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> <4D4C4C24.3070209@redpill-linpro.com> <1297090152.26424.11.camel@shakira.millnert.se> <4D500CF7.70601@redpill-linpro.com> <1297092572.26424.27.camel@shakira.millnert.se> <4D50110D.5080709@redpill-linpro.com> <4D501283.6050007@brightok.net> <3EC4E310-B4BC-4861-BD71-ADACF0E49664@network-heretics.com> In-Reply-To: <3EC4E310-B4BC-4861-BD71-ADACF0E49664@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 16:09:45 -0000 On 2/7/2011 9:52 AM, Keith Moore wrote: > So I think your recommendation against ever advertising a 2002 address in DNS is overbroad. > If the IETF is going to set a draft with recommendations, the draft should take into account the entire picture. ie, servers shouldn't advertise 6to4 via AAAA but they should support it or make sure they have a 6to4 relay router to handle responses that do come via 6to4. All ISPs should support anycast 6to4 addressing to support any clients which do not have other IPv6 options available. In addition, cases where the provider does provide CGN, NPTv6 can be used on the anycast relay to allow it to work with the hidden addressing. Providers are recommended to use native or at least a transition mechanism other than 6to4 as quickly as possible. > And I find it completely unacceptable to use CGN as an excuse to discourage use of 6to4. I'm not discouraging use of 6to4. I'm providing an appropriate scope where it is more functional. Encouraging: - use of anycast relays by ISPs to support hosts who have no other IPv6 capability - support on servers to reply to 6to4 addressing or at least have a known relay to handle the conversion. Discouraging: - advertising 2002::/16 addresses via DNS, as it promotes direct connectivity from 6to4 clients which may break communication - using 6to4 as the only means of a server to talk IPv6 (if you can setup a server, you can setup a static tunnel) The idea is that you provide a complete package in the recommendation. People who don't follow the recommendation cause their own grief, as 6to4 itself is a poor transition technology. Jack From martin@millnert.se Mon Feb 7 08:12:47 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF183A6E10 for ; Mon, 7 Feb 2011 08:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOZScqwbp6n1 for ; Mon, 7 Feb 2011 08:12:46 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by core3.amsl.com (Postfix) with ESMTP id 2530C3A6E0F for ; Mon, 7 Feb 2011 08:12:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 2F87D7791; Mon, 7 Feb 2011 17:17:28 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VI1l3dPCSKxj; Mon, 7 Feb 2011 17:17:28 +0100 (CET) Received: from [IPv6:2a02:9a0:100:2300::6] (shakira-work.us.millnert.se [IPv6:2a02:9a0:100:2300::6]) by ncis.csbnet.se (Postfix) with ESMTPSA id CBD1A78B; Mon, 7 Feb 2011 17:17:26 +0100 (CET) From: Martin Millnert To: Tore Anderson In-Reply-To: <4D50110D.5080709@redpill-linpro.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> <4D4C4C24.3070209@redpill-linpro.com> <1297090152.26424.11.camel@shakira.millnert.se> <4D500CF7.70601@redpill-linpro.com> <1297092572.26424.27.camel@shakira.millnert.se> <4D50110D.5080709@redpill-linpro.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Feb 2011 11:12:41 -0500 Message-ID: <1297095161.26424.40.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 16:12:47 -0000 On Mon, 2011-02-07 at 16:34 +0100, Tore Anderson wrote: > * Martin Millnert > > > Right, I need to further quality my '6to4 relay'. I meant 6to4 relay as > > ISP operated relays. They quite necessarily need to have "6to4 > > enabled". :) > > My main gripe is the «by default» bit. I'd be equally upset if C or J or > any other ISP-grade router vendor started announcing 2002::/16 or > 192.88.99.1/24 into the DFZ without the network admin first needing to > explicitly configure it... :-) > Haha, yes, of course. :) Wouldn't that be funny though. Regards, Martin From jbates@brightok.net Mon Feb 7 08:16:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE803A6D03 for ; Mon, 7 Feb 2011 08:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.154 X-Spam-Level: X-Spam-Status: No, score=-3.154 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ez3WOBTIAyhQ for ; Mon, 7 Feb 2011 08:16:24 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id AC82A3A6E1B for ; Mon, 7 Feb 2011 08:16:24 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17GGSpn003947; Mon, 7 Feb 2011 10:16:29 -0600 (CST) Message-ID: <4D501ADC.1060109@brightok.net> Date: Mon, 07 Feb 2011 10:16:28 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> <4D4C4C24.3070209@redpill-linpro.com> <1297090152.26424.11.camel@shakira.millnert.se> <4D500CF7.70601@redpill-linpro.com> <1297092572.26424.27.camel@shakira.millnert.se> <4D50110D.5080709@redpill-linpro.com> <4D501283.6050007@brightok.net> <3EC4E310-B4BC-4861-BD71-ADACF0E49664@network-heretics.com> In-Reply-To: <3EC4E310-B4BC-4861-BD71-ADACF0E49664@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 16:16:25 -0000 On 2/7/2011 9:52 AM, Keith Moore wrote: > I do this all the time, and it generally works well. Of course one > of the reasons that I do this is because I don't have enough IPv4 > addresses to assign to all of my hosts. If you're running a server with AAAA addresses, get a tunnel or native IPv6 or even 6rd. Using 6to4 as the primary means of a server's connectivity is ill advised. Responding to 6to4 is fine and should definitely be supported. The key on responding to 6to4 is that the operator of the server MUST know that there is a 6to4 relay to covert back to 6to4, or their server must be able to do it. 6to4 works best as a client mechanism, as clients often don't have the ability to manually setup a tunnel for native IPv6 addressing. It is substandard to 6rd and teredo. Jack From remi.despres@free.fr Mon Feb 7 08:33:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25923A6B06 for ; Mon, 7 Feb 2011 08:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.317 X-Spam-Level: X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1nl6rk3UTuo for ; Mon, 7 Feb 2011 08:33:58 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by core3.amsl.com (Postfix) with ESMTP id 487303A6959 for ; Mon, 7 Feb 2011 08:33:58 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2306.sfr.fr (SMTP Server) with ESMTP id 2FB027000083; Mon, 7 Feb 2011 17:34:02 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2306.sfr.fr (SMTP Server) with ESMTP id 959F67000087; Mon, 7 Feb 2011 17:34:01 +0100 (CET) X-SFR-UUID: 20110207163401612.959F67000087@msfrf2306.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <0EA7E738-697C-4AC9-91CD-682BCC8D7FFE@network-heretics.com> Date: Mon, 7 Feb 2011 17:33:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> <3AC337CC-1230-4E4B-A4D2-2E25FD832512@network-heretics.com> <4D5006DB.3040209@brightok.net> <0EA7E738-697C-4AC9-91CD-682BCC8D7FFE@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 16:33:59 -0000 Le 7 f=E9vr. 2011 =E0 16:07, Keith Moore a =E9crit : >=20 > On Feb 7, 2011, at 9:51 AM, Jack Bates wrote: >=20 >> On 2/7/2011 8:35 AM, Keith Moore wrote: >>> Yes, but IPv4 NAT will break applications that 6to4 will not. Given >>> the choice between a v6 address and a NATted v4 address, the former >>> will often (though not always) work better. Furthermore if the CPE >>> is provided by an ISP, the ISP can make sure that its relay routers >>> work. >>>=20 >>=20 >> I agree, if CGN wasn't going to exist. However, it will be, and I see = direct 6to4 breaking. The way around this is for 6to4 to be properly = supported by the ISP (see my other responses) >=20 > maybe the way around it is for all ISPs that implement CGN to also = implement native v6 via some means. the people that cause breakage need = to assume some responsibility for fixing the breakage. =20 Absolutely. In particular, most if not all ISPs that supports the 6to4 relay = function should extend it to support 6rd because: - the cost should be extremely limited - the effect is (without breaking 6to4) to offer native addresses to = sites whose CPEs supports 6rd (see for example = http://www.gossamer-threads.com/lists/nsp/ipv6/27039) Regards, RD From iesg-secretary@ietf.org Mon Feb 7 08:42:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D7E3A6D7D; Mon, 7 Feb 2011 08:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0Wf8mFbZetb; Mon, 7 Feb 2011 08:42:32 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6C93A6D6E; Mon, 7 Feb 2011 08:42:32 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110207164232.29375.38852.idtracker@localhost> Date: Mon, 07 Feb 2011 08:42:32 -0800 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Mobile Networks Considerations for IPv6 Deployment) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 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, 07 Feb 2011 16:42:33 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Mobile Networks Considerations for IPv6 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-02-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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-in-mobile-networks/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-in-mobile-networks/ Abstract Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. No IPR declarations have been submitted directly on this I-D. From tore@redpill-linpro.com Mon Feb 7 08:43:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE703A6E0F for ; Mon, 7 Feb 2011 08:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1tQoIph2zK1 for ; Mon, 7 Feb 2011 08:43:33 -0800 (PST) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id E4C023A6D94 for ; Mon, 7 Feb 2011 08:43:32 -0800 (PST) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id DC9191DB2CA; Mon, 7 Feb 2011 17:43:36 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mailhub.linpro.no Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id KOPqrB5oioWn; Mon, 7 Feb 2011 17:43:29 +0100 (CET) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Mon, 7 Feb 2011 17:43:29 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 1A351170C00A; Mon, 7 Feb 2011 17:43:29 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnZ1OMKVTENF; Mon, 7 Feb 2011 17:43:28 +0100 (CET) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id C0F55170C00B; Mon, 7 Feb 2011 17:43:28 +0100 (CET) Date: Mon, 7 Feb 2011 17:43:28 +0100 (CET) From: Tore Anderson To: Ole Troan Message-ID: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 16:47:36 -0000 * Ole Troan > I just posted the following draft suggesting that we move the 6to4 > documents to historic. Ole, I agree fully. Thank you for writing the draft. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From dr@cluenet.de Mon Feb 7 09:23:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894183A6E39 for ; Mon, 7 Feb 2011 09:23:44 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-uGfjKngsuy for ; Mon, 7 Feb 2011 09:23:43 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 8B33A3A6E37 for ; Mon, 7 Feb 2011 09:23:43 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 478E11080A2; Mon, 7 Feb 2011 18:23:46 +0100 (CET) Date: Mon, 7 Feb 2011 18:23:46 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110207172346.GA28658@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <20110207151430.44A393A6DD8@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 17:23:44 -0000 On Mon, Feb 07, 2011 at 04:17:48PM +0100, Ole Troan wrote: > > 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 [RFC3056] is moved to historic status. Fully agreed, I support this request. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From moore@network-heretics.com Mon Feb 7 09:39:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181E43A6E4A for ; Mon, 7 Feb 2011 09:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpCThn2L7i7A for ; Mon, 7 Feb 2011 09:39:56 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 227613A6E47 for ; Mon, 7 Feb 2011 09:39:56 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmV48-00058F-T1; Mon, 07 Feb 2011 12:40:00 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D50194B.4030500@brightok.net> Date: Mon, 7 Feb 2011 12:39:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> <4D4C4C24.3070209@redpill-linpro.com> <1297090152.26424.11.camel@shakira.millnert.se> <4D500CF7.70601@redpill-linpro.com> <1297092572.26424.27.camel@shakira.millnert.se> <4D50110D.5080709@redpill-linpro.com> <4D501283.6050007@brightok.net> <3EC4E310-B4BC-4861-BD71-ADACF0E49664@network-heretics.com> <4D50194B.4030500@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94091532d93adf24250672b174fbfa43d87350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 17:39:57 -0000 On Feb 7, 2011, at 11:09 AM, Jack Bates wrote: > On 2/7/2011 9:52 AM, Keith Moore wrote: >> So I think your recommendation against ever advertising a 2002 = address in DNS is overbroad. >>=20 >=20 > If the IETF is going to set a draft with recommendations, the draft = should take into account the entire picture. ie, servers shouldn't = advertise 6to4 via AAAA but they should support it or make sure they = have a 6to4 relay router to handle responses that do come via 6to4. No. that's way overbroad. You're making assumptions about servers (and = clients) which aren't true in general. =20 > All ISPs should support anycast 6to4 addressing to support any clients = which do not have other IPv6 options available. In addition, cases where = the provider does provide CGN, NPTv6 can be used on the anycast relay to = allow it to work with the hidden addressing. Providers are recommended = to use native or at least a transition mechanism other than 6to4 as = quickly as possible. >=20 >> And I find it completely unacceptable to use CGN as an excuse to = discourage use of 6to4. >=20 > I'm not discouraging use of 6to4. I'm providing an appropriate scope = where it is more functional. >=20 > Encouraging: >=20 > - use of anycast relays by ISPs to support hosts who have no other = IPv6 capability > - support on servers to reply to 6to4 addressing or at least have a = known relay to handle the conversion. >=20 > Discouraging: >=20 > - advertising 2002::/16 addresses via DNS, as it promotes direct = connectivity from 6to4 clients which may break communication > - using 6to4 as the only means of a server to talk IPv6 (if you can = setup a server, you can setup a static tunnel) >=20 Again, overbroad. Just as one example, if 6to4 is the only way to = contact a server from outside of its local network, then it's entirely = appropriate to advertise that server's 6to4 address in DNS. =20 Also, it's not the case that every application that uses DNS to obtain = destination addresses, works better over NATted v4 than over 6to4. DNS does not exist merely to advertise web servers and email MXes. = Whether it makes sense to advertise a 2002:: address via an AAAA record = is highly dependent on how that host is used, what its clients are, etc. = Your recommendation might make sense for a domain that is only used for = a web server, but it doesn't make sense in general. Keith From moore@network-heretics.com Mon Feb 7 09:43:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A66213A6E48 for ; Mon, 7 Feb 2011 09:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f82Lc8KDxo-e for ; Mon, 7 Feb 2011 09:43:37 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id BCD123A6A42 for ; Mon, 7 Feb 2011 09:43:37 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmV7l-0004Wx-KH; Mon, 07 Feb 2011 12:43:42 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D501ADC.1060109@brightok.net> Date: Mon, 7 Feb 2011 12:43:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <834FEC16-B29D-40E1-9865-1FC0C1960F7F@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> <4D4C4C24.3070209@redpill-linpro.com> <1297090152.26424.11.camel@shakira.millnert.se> <4D500CF7.70601@redpill-linpro.com> <1297092572.26424.27.camel@shakira.millnert.se> <4D50110D.5080709@redpill-linpro.com> <4D501283.6050007@brightok.net> <3EC4E310-B4BC-4861-BD71-ADACF0E49664@network-heretics.com> <4D501ADC.1060109@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940ea7ec3c0f16b5842fdaf67daba014220350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 17:43:38 -0000 On Feb 7, 2011, at 11:16 AM, Jack Bates wrote: >=20 > On 2/7/2011 9:52 AM, Keith Moore wrote: >> I do this all the time, and it generally works well. Of course one >> of the reasons that I do this is because I don't have enough IPv4 >> addresses to assign to all of my hosts. >=20 >=20 > If you're running a server with AAAA addresses, get a tunnel or native = IPv6 or even 6rd. In my experience configured tunnels are much worse than 6to4. Also, = 6to4 is available to me without my having to make any special = arrangements with anybody else. That's very powerful, and you're way = out of line for trying to impair that functionality. > Using 6to4 as the primary means of a server's connectivity is ill = advised. It's the best that's available to me right now. I'll stop using it as a = primary means of connectivity as soon as I find a reasonable ISP that = provides native v6 at a reasonable price. > 6to4 works best as a client mechanism, as clients often don't have the = ability to manually setup a tunnel for native IPv6 addressing. It is = substandard to 6rd and teredo. My experience indicates otherwise. Keith From moore@network-heretics.com Mon Feb 7 09:45:54 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E0913A6E4A for ; Mon, 7 Feb 2011 09:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhpLTenI9iyK for ; Mon, 7 Feb 2011 09:45:53 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 3DE083A6E3E for ; Mon, 7 Feb 2011 09:45:53 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmV9v-0001Jj-1A; Mon, 07 Feb 2011 12:45:57 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: Date: Mon, 7 Feb 2011 12:45:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4B12A44C-5024-409B-8827-9911E3FFA6EF@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> <3AC337CC-1230-4E4B-A4D2-2E25FD832512@network-heretics.com> <4D5006DB.3040209@brightok.net> <0EA7E738-697C-4AC9-91CD-682BCC8D7FFE@network-heretics.com> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94014f36094ec95dcf3e4945542118de244350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 17:45:54 -0000 On Feb 7, 2011, at 11:33 AM, R=E9mi Despr=E9s wrote: >=20 > Le 7 f=E9vr. 2011 =E0 16:07, Keith Moore a =E9crit : >=20 >>=20 >> On Feb 7, 2011, at 9:51 AM, Jack Bates wrote: >>=20 >>> On 2/7/2011 8:35 AM, Keith Moore wrote: >>>> Yes, but IPv4 NAT will break applications that 6to4 will not. = Given >>>> the choice between a v6 address and a NATted v4 address, the former >>>> will often (though not always) work better. Furthermore if the CPE >>>> is provided by an ISP, the ISP can make sure that its relay routers >>>> work. >>>>=20 >>>=20 >>> I agree, if CGN wasn't going to exist. However, it will be, and I = see direct 6to4 breaking. The way around this is for 6to4 to be properly = supported by the ISP (see my other responses) >>=20 >> maybe the way around it is for all ISPs that implement CGN to also = implement native v6 via some means. the people that cause breakage need = to assume some responsibility for fixing the breakage. =20 >=20 > Absolutely. > In particular, most if not all ISPs that supports the 6to4 relay = function should extend it to support 6rd because: > - the cost should be extremely limited > - the effect is (without breaking 6to4) to offer native addresses to = sites whose CPEs supports 6rd (see for example = http://www.gossamer-threads.com/lists/nsp/ipv6/27039) I'm all for ISPs supporting 6rd. Though if they want to implement pure = v6 instead, that's also fine w/me. I just don't think that ISPs should = break a standard IPv6 transmission mechanism without providing some form = of real IPv6. Keith From moore@network-heretics.com Mon Feb 7 09:47:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1549C3A6DD5 for ; Mon, 7 Feb 2011 09:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Psnnb1Fx9gpL for ; Mon, 7 Feb 2011 09:47:33 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 59CB93A6E3E for ; Mon, 7 Feb 2011 09:47:33 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmVBX-0006uL-QJ; Mon, 07 Feb 2011 12:47:37 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> Date: Mon, 7 Feb 2011 12:47:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> To: Tore Anderson X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940abbb36c0e3f7956feb03e2050fe3f8a3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 17:47:34 -0000 On Feb 7, 2011, at 11:43 AM, Tore Anderson wrote: > * Ole Troan >=20 >> I just posted the following draft suggesting that we move the 6to4 >> documents to historic. >=20 > Ole, >=20 > I agree fully. Thank you for writing the draft. I strongly disagree. You're trying to kill the most widely deployed v6 = transition mechanism that we have, without there being anything like a = suitable replacement. The fix for 6to4's problems is proper network configuration. Keith From dr@cluenet.de Mon Feb 7 09:56:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B29F3A6E51 for ; Mon, 7 Feb 2011 09:56:22 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0ta1-RDDtpC for ; Mon, 7 Feb 2011 09:56:21 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 21EFB3A6E4C for ; Mon, 7 Feb 2011 09:56:20 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id BC45F1080B7; Mon, 7 Feb 2011 18:56:24 +0100 (CET) Date: Mon, 7 Feb 2011 18:56:24 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110207175624.GA929@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 17:56:22 -0000 On Mon, Feb 07, 2011 at 12:47:25PM -0500, Keith Moore wrote: > I strongly disagree. You're trying to kill the most widely deployed > v6 transition mechanism that we have, without there being anything > like a suitable replacement. 6RD. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From moore@network-heretics.com Mon Feb 7 09:58:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317AF3A6E55 for ; Mon, 7 Feb 2011 09:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAlpRRbdVBqI for ; Mon, 7 Feb 2011 09:58:00 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 57B8B3A6E4C for ; Mon, 7 Feb 2011 09:58:00 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmVLf-0000Od-Mt; Mon, 07 Feb 2011 12:58:04 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110207175624.GA929@srv03.cluenet.de> Date: Mon, 7 Feb 2011 12:57:49 -0500 Content-Transfer-Encoding: 7bit Message-Id: <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9402e9ab70686951171fab5149b7cb955b2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 17:58:01 -0000 On Feb 7, 2011, at 12:56 PM, Daniel Roesen wrote: > On Mon, Feb 07, 2011 at 12:47:25PM -0500, Keith Moore wrote: >> I strongly disagree. You're trying to kill the most widely deployed >> v6 transition mechanism that we have, without there being anything >> like a suitable replacement. > > 6RD. 6rd is great for ISPs. It doesn't solve the problem for individual users. Keith From Fred.L.Templin@boeing.com Mon Feb 7 10:04:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE08B3A6E51 for ; Mon, 7 Feb 2011 10:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWoWwcMXTFfo for ; Mon, 7 Feb 2011 10:04:17 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 3B14C3A6961 for ; Mon, 7 Feb 2011 10:04:17 -0800 (PST) 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 p17I4Caw001756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Feb 2011 10:04:17 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p17I4BMH018579; Mon, 7 Feb 2011 12:04:11 -0600 (CST) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p17I4A6G018546 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 7 Feb 2011 12:04:11 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Mon, 7 Feb 2011 10:04:10 -0800 From: "Templin, Fred L" To: Daniel Roesen , "v6ops@ietf.org" Date: Mon, 7 Feb 2011 10:04:08 -0800 Thread-Topic: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 Thread-Index: AcvG8HDbZPvT1NcHSLKT/tlsSqLKnwAAK7cA Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> In-Reply-To: <20110207175624.GA929@srv03.cluenet.de> 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] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:04:17 -0000 > 6RD. Why not something better? Why not IRON: http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt Fred fred.l.templin@boeing.com= From Ted.Lemon@nominum.com Mon Feb 7 10:10:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C153A6E56 for ; Mon, 7 Feb 2011 10:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YjHOoTzeuok for ; Mon, 7 Feb 2011 10:10:33 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 4D9DA3A6E66 for ; Mon, 7 Feb 2011 10:10:32 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTVA1nVMmABvZ7+y5dR+lArkPsjjmuDEy@postini.com; Mon, 07 Feb 2011 10:10:38 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 39EDD1B8275 for ; Mon, 7 Feb 2011 10:10:35 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 26FFF190052; Mon, 7 Feb 2011 10:10:35 -0800 (PST) (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; Mon, 7 Feb 2011 10:10:34 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Mon, 7 Feb 2011 13:10:30 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <266311A5-C619-453C-9F2E-9D8CBBE53D4C@nominum.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) Cc: "v6ops@ietf.org" , Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:10:41 -0000 On Feb 7, 2011, at 1:04 PM, Templin, Fred L wrote: > Why not something better? Why not IRON: I'm not deeply familiar with the protocol, but at first glance it seems = to be a system for balkanizing the Internet. In what respect is this = "something better?" Am I misunderstanding what the protocol does? From jbates@brightok.net Mon Feb 7 10:12:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33AC33A6E56 for ; Mon, 7 Feb 2011 10:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0euCS1poJ3wz for ; Mon, 7 Feb 2011 10:12:32 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 27CF23A6C87 for ; Mon, 7 Feb 2011 10:12:32 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p17ICaMw007131; Mon, 7 Feb 2011 12:12:36 -0600 (CST) Message-ID: <4D503614.4090304@brightok.net> Date: Mon, 07 Feb 2011 12:12:36 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> <4D4C4C24.3070209@redpill-linpro.com> <1297090152.26424.11.camel@shakira.millnert.se> <4D500CF7.70601@redpill-linpro.com> <1297092572.26424.27.camel@shakira.millnert.se> <4D50110D.5080709@redpill-linpro.com> <4D501283.6050007@brightok.net> <3EC4E310-B4BC-4861-BD71-ADACF0E49664@network-heretics.com> <4D50194B.4030500@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:12:34 -0000 On 2/7/2011 11:39 AM, Keith Moore wrote: > Again, overbroad. Just as one example, if 6to4 is the only way to > contact a server from outside of its local network, then it's > entirely appropriate to advertise that server's 6to4 address in DNS. > This makes the assumption that 6to4 is the ONLY mechanism for IPv6 transition for a server. I would argue that any server which requires 6to4 to be operational is substandard at best. There is an expectation that a server should have better capabilities than a client, and as such should be able to create static tunnels or similar to obtain native IPv6. > Also, it's not the case that every application that uses DNS to > obtain destination addresses, works better over NATted v4 than over > 6to4. Except if the NAT is at the service provider, the 6to4 being chosen will cause an immediate break. > DNS does not exist merely to advertise web servers and email MXes. > Whether it makes sense to advertise a 2002:: address via an AAAA > record is highly dependent on how that host is used, what its > clients are, etc. Your recommendation might make sense for a domain > that is only used for a web server, but it doesn't make sense in > general. > It makes perfect sense in general, especially given that 6to4 should be made historic anyways. Your position of advertising it via DNS requires a lot of conditionals which should not be expected out of 6to4, when the networks are migrating into more hostile 6to4 environments. You are stating: - A server may require 6to4 for connectivity I say 6to4 servers are broken. Get a nailed up tunnel. There are plenty of free ones out there. If we are talking p2p, it's a crap shoot. From your other response you stated: > In my experience configured tunnels are much worse than 6to4. Also, > 6to4 is available to me without my having to make any special > arrangements with anybody else. That's very powerful, and you're way > out of line for trying to impair that functionality. I find that people who say tunnels are much worse are referring to the latency problem which 6to4 CAN overcome by using the same route as IPv4, or the problem with IPv6 isolated networks. However, as native IPv6 paths are corrected through the core networks and CGN becomes more common for IPv4, using 6to4 in this way will make your connectivity MUCH worse. In other words, it is a timing issue. Pre-IPv6 deployment of core networks, 6to4 had some benefits. As IPv6 becomes more dominate in core networks, 6to4 will more often than not break when depended on by servers. - 6to4 connectivity is sometimes better than NAT44 I agree, except IPv4 connectivity will be worse over time and NAT444 is better than 6to4 not working at all. A client could change address selection policies to prefer 6to4 via anycast over any IPv4, but that is a per client decision and should not be made standard. It is a question of what works best in most situations. 6to4 should be marked historic, and the server applications of 6to4 should definitely not be used (outside of supporting a 6to4 response). Honestly, quit support IPv4 by running 6to4 servers. Move on to native. If the latency sucks, work to fix it. Jack From jhw@apple.com Mon Feb 7 10:21:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C103A6E49 for ; Mon, 7 Feb 2011 10:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33OxmqTrjUUl for ; Mon, 7 Feb 2011 10:21:04 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id ECEC33A6E5F for ; Mon, 7 Feb 2011 10:21:03 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id D6A26CD23B05 for ; Mon, 7 Feb 2011 10:21:08 -0800 (PST) X-AuditID: 11807130-b7b3cae00000405d-c7-4d5038149295 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay11.apple.com (Apple SCV relay) with SMTP id 64.CA.16477.418305D4; Mon, 7 Feb 2011 10:21:08 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from il0602f-dhcp196.apple.com (il0602f-dhcp196.apple.com [17.206.50.196]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LG900MVAEZ8KGA0@gertie.apple.com> for v6ops@ietf.org; Mon, 07 Feb 2011 10:21:08 -0800 (PST) From: james woodyatt In-reply-to: Date: Mon, 07 Feb 2011 10:21:08 -0800 Message-id: References: <20110207151430.44A393A6DD8@core3.amsl.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:21:05 -0000 On Feb 7, 2011, at 07:17, Ole Troan wrote: >> 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 [RFC3056] is moved to historic status. Objection: it's too soon to move this protocol to historic. The 6to4 protocol is still in widespread use, despite its suboptimality for promoting IPv6 transition, particularly in residential IPv4/NAT gateways. I don't even think it's yet time to move RFC 3068 to Historic status, which would arguably be slightly more sane to contemplate, but moving RFC 3056 to Historic at this point would be far too aggressive. All that said, I further worry that moving RFC 3056 to Historic status would conflict with the very worthy recommendations concerning deployments of 6to4 relay routers in I-D.carpenter-v6ops-6to4-teredo-advisory. This is probably the best reason not to move RFC 3056 to Historic status at this time. -- james woodyatt member of technical staff, communications engineering From Fred.L.Templin@boeing.com Mon Feb 7 10:22:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90BC43A6E41 for ; Mon, 7 Feb 2011 10:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvfDSzKC1xbz for ; Mon, 7 Feb 2011 10:22:23 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 87BF13A6E49 for ; Mon, 7 Feb 2011 10:22:23 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p17IMGcA003007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Feb 2011 10:22:20 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p17IMGSU017516; Mon, 7 Feb 2011 10:22:16 -0800 (PST) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p17IMGoH017513 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 7 Feb 2011 10:22:16 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Mon, 7 Feb 2011 10:22:16 -0800 From: "Templin, Fred L" To: Ted Lemon Date: Mon, 7 Feb 2011 10:22:14 -0800 Thread-Topic: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 Thread-Index: AcvG8lbxr6oyFI28TpCVGuO/azkhdAAAGn/w Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <266311A5-C619-453C-9F2E-9D8CBBE53D4C@nominum.com> In-Reply-To: <266311A5-C619-453C-9F2E-9D8CBBE53D4C@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:22:24 -0000 Hi Ted, You'll have to educate me on what you mean by "balkanizing" the Internet, because the concept is totally foreign to me at least within the context of IRON? As to how IRON is better, do you want an exhaustive list or just a few for-instances? I'll give you a few for- instances for now, and you can tell me if you'd like me to expand on it: 1) Supports use of a single, stable IP address/prefix across multiple provider connections 2) Natural incremental IPv6 deployment w/o need for IPv4-embedded IPv6 address formats 3) Natural support for NAT traversal=20 4) No need to upgrage/replace CPE routers 5) Mobility management as an in-built feature of the architecture. 6) Solves tunnel path MTU interactions 7) list continues on from here... Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Monday, February 07, 2011 10:11 AM > To: Templin, Fred L > Cc: Daniel Roesen; v6ops@ietf.org > Subject: Re: [v6ops] Fwd: New Version Notificationfor=20 > draft-troan-v6ops-6to4-to-historic-00 >=20 > On Feb 7, 2011, at 1:04 PM, Templin, Fred L wrote: > > Why not something better? Why not IRON: >=20 > I'm not deeply familiar with the protocol, but at first=20 > glance it seems to be a system for balkanizing the Internet. =20 > In what respect is this "something better?" Am I=20 > misunderstanding what the protocol does? >=20 > = From jbates@brightok.net Mon Feb 7 10:23:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681DE3A6E60 for ; Mon, 7 Feb 2011 10:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9hVnpHR-O6i for ; Mon, 7 Feb 2011 10:23:27 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 817F13A6E6C for ; Mon, 7 Feb 2011 10:23:27 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17INLFK011842; Mon, 7 Feb 2011 12:23:21 -0600 (CST) Message-ID: <4D503899.1060807@brightok.net> Date: Mon, 07 Feb 2011 12:23:21 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <4D4A2401.2020500@gmail.com> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> <3AC337CC-1230-4E4B-A4D2-2E25FD832512@network-heretics.com> <4D5006DB.3040209@brightok.net> <0EA7E738-697C-4AC9-91CD-682BCC8D7FFE@network-heretics.com> <4B12A44C-5024-409B-8827-9911E3FFA6EF@network-heretics.com> In-Reply-To: <4B12A44C-5024-409B-8827-9911E3FFA6EF@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:23:28 -0000 On 2/7/2011 11:45 AM, Keith Moore wrote: > I just don't think that ISPs should break a standard IPv6 > transmission mechanism without providing some form of real IPv6. It's not your decision to make, and it will happen out of necessity. Servers choosing to advertise 6to4 do so at their own risk. If an ISP is forced to rely on 6to4 as a fallback, they will support NPTv6 on the 6to4 relays. It's the only viable option for 6to4 in CGN. Get a tunnel. Quit supporting a dying protocol that should have been 6rd to begin with (so we'd have lots of 6rd implementations instead of broken 6to4). Jack From gert@space.net Mon Feb 7 10:24:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A529D3A6E6C for ; Mon, 7 Feb 2011 10:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s14oqH2rhC6Q for ; Mon, 7 Feb 2011 10:24:25 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by core3.amsl.com (Postfix) with ESMTP id 86D163A6E60 for ; Mon, 7 Feb 2011 10:24:24 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 99E6EF8160 for ; Mon, 7 Feb 2011 19:24:27 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 86FEFF80DE for ; Mon, 7 Feb 2011 19:24:27 +0100 (CET) Received: (qmail 25374 invoked by uid 1007); 7 Feb 2011 19:24:27 +0100 Date: Mon, 7 Feb 2011 19:24:27 +0100 From: Gert Doering To: Keith Moore Message-ID: <20110207182427.GX44800@Space.Net> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:24:25 -0000 Hi, On Mon, Feb 07, 2011 at 12:57:49PM -0500, Keith Moore wrote: > 6rd is great for ISPs. It doesn't solve the problem for individual users. Neither does 6to4 with badly deployed anycast relays. 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 Ted.Lemon@nominum.com Mon Feb 7 10:27:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D11D3A6E41 for ; Mon, 7 Feb 2011 10:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BI2tacVAtdUm for ; Mon, 7 Feb 2011 10:27:43 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 7AA033A6C87 for ; Mon, 7 Feb 2011 10:27:43 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTVA5owqKfPmwdq/G8FiohkdQojqw8xAl@postini.com; Mon, 07 Feb 2011 10:27:48 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7D11D1B82FA for ; Mon, 7 Feb 2011 10:27:47 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3AAD1190052; Mon, 7 Feb 2011 10:27:47 -0800 (PST) (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; Mon, 7 Feb 2011 10:27:46 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4D503614.4090304@brightok.net> Date: Mon, 7 Feb 2011 13:27:42 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <53A234CF-EC05-4832-A864-F64572AAD725@nominum.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> <4D4C4C24.3070209@redpill-linpro.com> <1297090152.26424.11.camel@shakira.millnert.se> <4D500CF7.70601@redpill-linpro.com> <1297092572.26424.27.camel@shakira.millnert.se> <4D50110D.5080709@redpill-linpro.com> <4D501283.6050007@brightok.net> <3EC4E310-B4BC-4861-BD71-ADACF0E49664@network-heretics.com> <4D50194B.4030500@brightok.net> <4D503614.4090304@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:27:44 -0000 On Feb 7, 2011, at 1:12 PM, Jack Bates wrote: > This makes the assumption that 6to4 is the ONLY mechanism for IPv6 > transition for a server. I would argue that any server which requires > 6to4 to be operational is substandard at best. There is an expectation > that a server should have better capabilities than a client, and as = such > should be able to create static tunnels or similar to obtain native = IPv6. I think what you are mowing over here is the notion of near-peer-to-peer = servers. When Keith says "server," he means "any node that accepts = incoming connections, and needs to be contacted from elsewhere on the = Internet." What you mean when you say "server" is "a dedicated central = node configured to provide specific services to a broad range of = end-users." E.g., a web server or a streaming video server run by some = corporation, typically with some kind of income stream supporting it. So it's not surprising that you and Keith disagree on usage here. But = the use case Keith is describing is perfectly valid, and indeed, back in = the days before "server" meant "giant anycast cloud referred to with a = single name, from which we download content," most "servers" were of the = type Keith is referring to. Keith's use case is valid. Whether 6to4 in DNS is the right way to = address it is certainly up for debate, but let's not pretend that the = need Keith is describing doesn't exist, or doesn't matter. I agree = with Keith that the fact that CGN breaks his use case is a bug, not a = feature--that is, it is not a valid reason to deprecate 6to4. From gert@space.net Mon Feb 7 10:28:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3563A6E64 for ; Mon, 7 Feb 2011 10:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d79kbqJiHG4v for ; Mon, 7 Feb 2011 10:28:03 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by core3.amsl.com (Postfix) with ESMTP id 1B9FC3A6C87 for ; Mon, 7 Feb 2011 10:28:03 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 537F2F8160 for ; Mon, 7 Feb 2011 19:28:07 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 41064F80DE for ; Mon, 7 Feb 2011 19:28:07 +0100 (CET) Received: (qmail 27028 invoked by uid 1007); 7 Feb 2011 19:28:07 +0100 Date: Mon, 7 Feb 2011 19:28:07 +0100 From: Gert Doering To: Ole Troan Message-ID: <20110207182807.GY44800@Space.Net> References: <20110207151430.44A393A6DD8@core3.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: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:28:04 -0000 Hi, On Mon, Feb 07, 2011 at 04:17:48PM +0100, Ole Troan wrote: > I just posted the following draft suggesting that we move the 6to4 documents to historic. I think 3056 is harmless enough as it is, provided connectivity to "non-6to4" IPv6 is not happening (not *at all*, since you can't control the return path even if the outgoig relay is sane). 3068 is where the breakage comes from. 3056 with "only used for packets going to 2002: addresses, sourced from 2002: addresses" is useful. 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 Mon Feb 7 10:29:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57CDE3A6E69 for ; Mon, 7 Feb 2011 10:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSpDe4IV68pG for ; Mon, 7 Feb 2011 10:29:23 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 3127A3A6E41 for ; Mon, 7 Feb 2011 10:29:23 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmVpy-0003vV-4q; Mon, 07 Feb 2011 13:29:27 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D503614.4090304@brightok.net> Date: Mon, 7 Feb 2011 13:28:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <30434A2C-DC14-4E90-9EEB-FCEF32700219@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <36EBE2CE-B29E-41F2-9C0B-6D68931C2DAB@network-heretics.com> <4D4C4C24.3070209@redpill-linpro.com> <1297090152.26424.11.camel@shakira.millnert.se> <4D500CF7.70601@redpill-linpro.com> <1297092572.26424.27.camel@shakira.millnert.se> <4D50110D.5080709@redpill-linpro.com> <4D501283.6050007@brightok.net> <3EC4E310-B4BC-4861-BD71-ADACF0E49664@network-heretics.com> <4D50194B.4030500@brightok.net> <4D503614.4090304@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9407bc3cdb9982fde89411b3c3554b39ae6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:29:25 -0000 On Feb 7, 2011, at 1:12 PM, Jack Bates wrote: > On 2/7/2011 11:39 AM, Keith Moore wrote: >> Again, overbroad. Just as one example, if 6to4 is the only way to >> contact a server from outside of its local network, then it's >> entirely appropriate to advertise that server's 6to4 address in DNS. >>=20 >=20 > This makes the assumption that 6to4 is the ONLY mechanism for IPv6 > transition for a server. I would argue that any server which requires > 6to4 to be operational is substandard at best. There is an expectation > that a server should have better capabilities than a client, and as = such > should be able to create static tunnels or similar to obtain native = IPv6. WTF? =20 Look, the Internet is not about a client-server paradigm. The Internet = is fundamentally, and architecturally, peer to peer. There is no such = expectation about servers in the Internet - there is actually no such = thing as a "server" (as distinct from a "client") in the Internet = architecture. There are only hosts that send and receive packets. = Being able to accept a SYN TCP packet and return a SYN ACK TCP packet in = response, is a perfectly normal thing for any Internet host to do. =20 >> Also, it's not the case that every application that uses DNS to >> obtain destination addresses, works better over NATted v4 than over >> 6to4. >=20 > Except if the NAT is at the service provider, the 6to4 being chosen = will > cause an immediate break. If my ISP imposes a NAT on my connection, I will get another ISP THAT = VERY DAY. =20 >> DNS does not exist merely to advertise web servers and email MXes. >> Whether it makes sense to advertise a 2002:: address via an AAAA >> record is highly dependent on how that host is used, what its >> clients are, etc. Your recommendation might make sense for a domain >> that is only used for a web server, but it doesn't make sense in >> general. >>=20 >=20 > It makes perfect sense in general, especially given that 6to4 should = be > made historic anyways. your premise is false, so your conclusion is unwarranted. > Your position of advertising it via DNS requires > a lot of conditionals which should not be expected out of 6to4, when = the > networks are migrating into more hostile 6to4 environments. >=20 > You are stating: >=20 > - A server may require 6to4 for connectivity >=20 > I say 6to4 servers are broken. Get a nailed up tunnel. There are = plenty > of free ones out there. If we are talking p2p, it's a crap shoot. I've tried nailed up tunnels. They worked much worse for me than 6to4, = and were also more trouble to set up. >=20 > =46rom your other response you stated: >> In my experience configured tunnels are much worse than 6to4. Also, >> 6to4 is available to me without my having to make any special >> arrangements with anybody else. That's very powerful, and you're way >> out of line for trying to impair that functionality. >=20 > I find that people who say tunnels are much worse are referring to the = latency problem which 6to4 CAN overcome by using the same route as IPv4, = or the problem with IPv6 isolated networks. However, as native IPv6 = paths are corrected through the core networks and CGN becomes more = common for IPv4, using 6to4 in this way will make your connectivity MUCH = worse. As soon as people can get native v6 *everywhere* (that includes dialup/ = cell modem/hotels/starbucks/etc.), they'll have no need for 6to4. = Until that's the case, it's irresponsible to try to kill it.=20 > In other words, it is a timing issue. Pre-IPv6 deployment of core = networks, 6to4 had some benefits. As IPv6 becomes more dominate in core = networks, 6to4 will more often than not break when depended on by = servers. I don't see how deployment of v6 in core networks adversely affects = 6to4. And it only reduces the need for 6to4 when native v6 is = available. > - 6to4 connectivity is sometimes better than NAT44 >=20 > I agree, except IPv4 connectivity will be worse over time and NAT444 = is > better than 6to4 not working at all. Incorrect. There are cases where nat44 works better; there are also = cases where 6to4 works better. Force either one to the exclusion of = the other and you break more things than if you allow both. > A client could change address > selection policies to prefer 6to4 via anycast over any IPv4, but that = is > a per client decision and should not be made standard. Default address selection rules have always been naive. Applications = have to do their own address selection, in accordance with their own = needs, if they expect to work well in this hodgepodge of addressing and = routing scenarios. That will continue to be the case until every host = in the world has one and only one globally unique IPv6 address and no v4 = addresses. (in other words, it will continue for the foreseeable = future) > It is a question of what works best in most situations. NO, that is the wrong question to ask. Stop trying to make the whole = Internet act as if it were only using HTTP. Keith From moore@network-heretics.com Mon Feb 7 10:30:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC70A3A6E69 for ; Mon, 7 Feb 2011 10:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPN2PmXPGaLY for ; Mon, 7 Feb 2011 10:30:50 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id C03823A6C87 for ; Mon, 7 Feb 2011 10:30:45 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmVrL-0003vV-Qz; Mon, 07 Feb 2011 13:30:49 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110207182427.GX44800@Space.Net> Date: Mon, 7 Feb 2011 13:30:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940e1247a69085d18b7135a914a412b8c2d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:30:51 -0000 On Feb 7, 2011, at 1:24 PM, Gert Doering wrote: > Hi, >=20 > On Mon, Feb 07, 2011 at 12:57:49PM -0500, Keith Moore wrote: >> 6rd is great for ISPs. It doesn't solve the problem for individual = users. >=20 > Neither does 6to4 with badly deployed anycast relays. so fix the anycast relays. it's easier to do that than to get either = 6rd or pure v6 everywhere. Keith From dr@cluenet.de Mon Feb 7 10:33:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B92BE3A6A2F for ; Mon, 7 Feb 2011 10:33:16 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nL+s8HKPH0o for ; Mon, 7 Feb 2011 10:33:15 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 6B1F03A6C87 for ; Mon, 7 Feb 2011 10:33:15 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 524851080BA; Mon, 7 Feb 2011 19:33:19 +0100 (CET) Date: Mon, 7 Feb 2011 19:33:19 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110207183319.GA3331@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:33:16 -0000 On Mon, Feb 07, 2011 at 12:57:49PM -0500, Keith Moore wrote: > >> I strongly disagree. You're trying to kill the most widely deployed > >> v6 transition mechanism that we have, without there being anything > >> like a suitable replacement. > > > > 6RD. > > 6rd is great for ISPs. It doesn't solve the problem for individual users. And who does an individual user contact if "Internet doesn't work" due to 6to4? Correct, the ISP. Unfortunately the ISP has only a limited chance to "make it work" - 6RD at least facilitates that. Anycast 6to4 is a promise which won't be delivered in a globally working manner anymore. The operational community has realized that. 6RD is the variant which has a chance to be supportable yet lightweight (it just still needs RIPE RIR policy fixes to be really easily deployable). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From remi.despres@free.fr Mon Feb 7 10:35:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B893A6A2F for ; Mon, 7 Feb 2011 10:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.443 X-Spam-Level: X-Spam-Status: No, score=-1.443 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6waRjm46a9A for ; Mon, 7 Feb 2011 10:35:43 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by core3.amsl.com (Postfix) with ESMTP id 8F6FC3A6C87 for ; Mon, 7 Feb 2011 10:35:43 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id 0D2807000091; Mon, 7 Feb 2011 19:35:48 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id 9C3A97000087; Mon, 7 Feb 2011 19:35:47 +0100 (CET) X-SFR-UUID: 20110207183547640.9C3A97000087@msfrf2409.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4B12A44C-5024-409B-8827-9911E3FFA6EF@network-heretics.com> Date: Mon, 7 Feb 2011 19:35:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <05DA4FE8-9DDA-40B9-B7AB-DA5DC9E6CF96@free.fr> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> <3AC337CC-1230-4E4B-A4D2-2E25FD832512@network-heretics.com> <4D5006DB.3040209@brightok.net> <0EA7E738-697C-4AC9-91CD-682BCC8D7FFE@network-heretics.com> <4B12A44C-5024-409B-8827-9911E3FFA6EF@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:35:45 -0000 Le 7 f=E9vr. 2011 =E0 18:45, Keith Moore a =E9crit : >=20 > On Feb 7, 2011, at 11:33 AM, R=E9mi Despr=E9s wrote: >=20 >>=20 >> Le 7 f=E9vr. 2011 =E0 16:07, Keith Moore a =E9crit : >>=20 >>>=20 >>> On Feb 7, 2011, at 9:51 AM, Jack Bates wrote: >>>=20 >>>> On 2/7/2011 8:35 AM, Keith Moore wrote: >>>>> Yes, but IPv4 NAT will break applications that 6to4 will not. = Given >>>>> the choice between a v6 address and a NATted v4 address, the = former >>>>> will often (though not always) work better. Furthermore if the = CPE >>>>> is provided by an ISP, the ISP can make sure that its relay = routers >>>>> work. >>>>>=20 >>>>=20 >>>> I agree, if CGN wasn't going to exist. However, it will be, and I = see direct 6to4 breaking. The way around this is for 6to4 to be properly = supported by the ISP (see my other responses) >>>=20 >>> maybe the way around it is for all ISPs that implement CGN to also = implement native v6 via some means. the people that cause breakage need = to assume some responsibility for fixing the breakage. =20 >>=20 >> Absolutely. >> In particular, most if not all ISPs that supports the 6to4 relay = function should extend it to support 6rd because: >> - the cost should be extremely limited >> - the effect is (without breaking 6to4) to offer native addresses to = sites whose CPEs supports 6rd (see for example = http://www.gossamer-threads.com/lists/nsp/ipv6/27039) >=20 > I'm all for ISPs supporting 6rd. Though if they want to implement = pure v6 instead, that's also fine w/me. That's clearly better where it can be done, no doubt about it. > I just don't think that ISPs should break a standard IPv6 = transmission mechanism without providing some form of real IPv6. Not sure to understand what you mean. In any case: - 6rd provides "real" native IPv6 addresses. - It's virtue is that, where some intermediate devices aren't ready for = IPv6, native addresses can be deployed without waiting for these devices = to be upgraded.=20 Regards,=20 RD =20 >=20 > Keith >=20 From Fred.L.Templin@boeing.com Mon Feb 7 10:37:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 013EA3A6C87 for ; Mon, 7 Feb 2011 10:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcGnrLhOZrRy for ; Mon, 7 Feb 2011 10:37:04 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 2A8753A6A2F for ; Mon, 7 Feb 2011 10:37:03 -0800 (PST) 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 p17IaxS0012504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Feb 2011 12:36:59 -0600 (CST) 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 p17IaxD6023079; Mon, 7 Feb 2011 12:36:59 -0600 (CST) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p17IawE7023065 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 7 Feb 2011 12:36:59 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Mon, 7 Feb 2011 10:36:58 -0800 From: "Templin, Fred L" To: Keith Moore , Gert Doering Date: Mon, 7 Feb 2011 10:36:57 -0800 Thread-Topic: [v6ops] Fwd: New Version Notification fordraft-troan-v6ops-6to4-to-historic-00 Thread-Index: AcvG9UZh/u3hH4VGQHG6uiBudUqBfgAAFVLg Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com><20110207175624. GA929@srv03.cluenet.de><80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com><20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> In-Reply-To: <2718CADC-1084-420C-9B1D-61EE9154EA6B@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 Cc: "v6ops@ietf.org" , Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification fordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:37:05 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Keith Moore > Sent: Monday, February 07, 2011 10:31 AM > To: Gert Doering > Cc: v6ops@ietf.org; Daniel Roesen > Subject: Re: [v6ops] Fwd: New Version Notification=20 > fordraft-troan-v6ops-6to4-to-historic-00 >=20 > On Feb 7, 2011, at 1:24 PM, Gert Doering wrote: >=20 > > Hi, > >=20 > > On Mon, Feb 07, 2011 at 12:57:49PM -0500, Keith Moore wrote: > >> 6rd is great for ISPs. It doesn't solve the problem for=20 > individual users. > >=20 > > Neither does 6to4 with badly deployed anycast relays. >=20 > so fix the anycast relays. it's easier to do that than to=20 > get either 6rd or pure v6 everywhere. IRON also uses anycast relays. IRON service providers will naturally ensure well-managed deployments so as to provide a high-quality service to their customers. Fred fred.l.templin@boeing.com > Keith >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From dr@cluenet.de Mon Feb 7 10:37:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795303A6E75 for ; Mon, 7 Feb 2011 10:37:45 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-9+-2KG1Yuh for ; Mon, 7 Feb 2011 10:37:44 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 669A73A6E66 for ; Mon, 7 Feb 2011 10:37:44 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id B85F01080C7; Mon, 7 Feb 2011 19:37:48 +0100 (CET) Date: Mon, 7 Feb 2011 19:37:48 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110207183748.GB3331@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:37:45 -0000 On Mon, Feb 07, 2011 at 10:04:08AM -0800, Templin, Fred L wrote: > > 6RD. > > Why not something better? Why not IRON: Find a significant base of cheap CPE vendors supporting it, and an ecosystem for the ISP-side systems. All ready to deploy within the next few months in ~production quality, CPEs shipping in the numbers with many zeros (6+), and an residential customer market compatible price point (no, Cisco ISRs don't fit that). All that for something that is needed for only a very few years until access networks are dual-stack ready. Too late. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From moore@network-heretics.com Mon Feb 7 10:38:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F4D3A6CAB for ; Mon, 7 Feb 2011 10:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ7+kI0bpEg8 for ; Mon, 7 Feb 2011 10:38:44 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 5E8353A6C87 for ; Mon, 7 Feb 2011 10:38:44 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmVz6-0004u8-4r; Mon, 07 Feb 2011 13:38:49 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: <05DA4FE8-9DDA-40B9-B7AB-DA5DC9E6CF96@free.fr> Date: Mon, 7 Feb 2011 13:38:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <055B3D38-887C-42AC-B282-A22C0C91A596@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <4D4FFF68.2000403@brightok.net> <3AC337CC-1230-4E4B-A4D2-2E25FD832512@network-heretics.com> <4D5006DB.3040209@brightok.net> <0EA7E738-697C-4AC9-91CD-682BCC8D7FFE@network-heretics.com> <4B12A44C-5024-409B-8827-9911E3FFA6EF@network-heretics.com> <05DA4FE8-9DDA-40B9-B7AB-DA5DC9E6CF96@free.fr> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940bc4075b562068437d7ac54742b4fafed350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:38:45 -0000 On Feb 7, 2011, at 1:35 PM, R=E9mi Despr=E9s wrote: >=20 > Le 7 f=E9vr. 2011 =E0 18:45, Keith Moore a =E9crit : >=20 >>=20 >> On Feb 7, 2011, at 11:33 AM, R=E9mi Despr=E9s wrote: >>=20 >>>=20 >>> Le 7 f=E9vr. 2011 =E0 16:07, Keith Moore a =E9crit : >>>=20 >>>>=20 >>>> On Feb 7, 2011, at 9:51 AM, Jack Bates wrote: >>>>=20 >>>>> On 2/7/2011 8:35 AM, Keith Moore wrote: >>>>>> Yes, but IPv4 NAT will break applications that 6to4 will not. = Given >>>>>> the choice between a v6 address and a NATted v4 address, the = former >>>>>> will often (though not always) work better. Furthermore if the = CPE >>>>>> is provided by an ISP, the ISP can make sure that its relay = routers >>>>>> work. >>>>>>=20 >>>>>=20 >>>>> I agree, if CGN wasn't going to exist. However, it will be, and I = see direct 6to4 breaking. The way around this is for 6to4 to be properly = supported by the ISP (see my other responses) >>>>=20 >>>> maybe the way around it is for all ISPs that implement CGN to also = implement native v6 via some means. the people that cause breakage need = to assume some responsibility for fixing the breakage. =20 >>>=20 >>> Absolutely. >>> In particular, most if not all ISPs that supports the 6to4 relay = function should extend it to support 6rd because: >>> - the cost should be extremely limited >>> - the effect is (without breaking 6to4) to offer native addresses to = sites whose CPEs supports 6rd (see for example = http://www.gossamer-threads.com/lists/nsp/ipv6/27039) >>=20 >> I'm all for ISPs supporting 6rd. Though if they want to implement = pure v6 instead, that's also fine w/me. >=20 > That's clearly better where it can be done, no doubt about it. >=20 >> I just don't think that ISPs should break a standard IPv6 = transmission mechanism without providing some form of real IPv6. >=20 > Not sure to understand what you mean. > In any case: > - 6rd provides "real" native IPv6 addresses. > - It's virtue is that, where some intermediate devices aren't ready = for IPv6, native addresses can be deployed without waiting for these = devices to be upgraded.=20 sorry, by "real" IPv6 I meant something that uses the native v6 packet = format to end hosts, uses native globally scoped v6 addresses, and = provides non-NATted connectivity with the public v6 network. 6rd = certainly qualifies. Keith From moore@network-heretics.com Mon Feb 7 10:41:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321853A6CAB for ; Mon, 7 Feb 2011 10:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-cbsDALZrQ2 for ; Mon, 7 Feb 2011 10:41:33 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 4F8DA3A6C87 for ; Mon, 7 Feb 2011 10:41:33 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmW1l-0000d2-JD; Mon, 07 Feb 2011 13:41:35 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Mon, 7 Feb 2011 13:41:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <301687CB-96BD-41FF-B451-614CB5FACEA8@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com><20110207175624. GA929@srv03.cluenet.de><80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com><20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9406c38c1abed059aa5039d5acd8d9d259c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: "v6ops@ietf.org" , Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification fordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:41:34 -0000 On Feb 7, 2011, at 1:36 PM, Templin, Fred L wrote: >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 >> On Behalf Of Keith Moore >> Sent: Monday, February 07, 2011 10:31 AM >> To: Gert Doering >> Cc: v6ops@ietf.org; Daniel Roesen >> Subject: Re: [v6ops] Fwd: New Version Notification=20 >> fordraft-troan-v6ops-6to4-to-historic-00 >>=20 >> On Feb 7, 2011, at 1:24 PM, Gert Doering wrote: >>=20 >>> Hi, >>>=20 >>> On Mon, Feb 07, 2011 at 12:57:49PM -0500, Keith Moore wrote: >>>> 6rd is great for ISPs. It doesn't solve the problem for=20 >> individual users. >>>=20 >>> Neither does 6to4 with badly deployed anycast relays. >>=20 >> so fix the anycast relays. it's easier to do that than to=20 >> get either 6rd or pure v6 everywhere. >=20 > IRON also uses anycast relays. IRON service providers > will naturally ensure well-managed deployments so as > to provide a high-quality service to their customers. I'll take a look at IRON. But the salient question is whether it's = easier to fix 6to4 than to deploy IRON in a way that works better than = 6to4. It doesn't matter if IRON would work better if it were deployed = than 6to4 happens to work now. You have to consider both deployment = hurdles and operational issues for both cases, and you have to consider = that conditions will change by the time anything new would be deployed. Keith From Fred.L.Templin@boeing.com Mon Feb 7 10:42:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25CA3A6E41 for ; Mon, 7 Feb 2011 10:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dhNmp0FnbP4 for ; Mon, 7 Feb 2011 10:42:16 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 161B43A6D81 for ; Mon, 7 Feb 2011 10:42:16 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p17IgIqM015248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Feb 2011 10:42:18 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p17IgHC4007131; Mon, 7 Feb 2011 10:42:17 -0800 (PST) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p17IgHTr007122 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 7 Feb 2011 10:42:17 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Mon, 7 Feb 2011 10:42:17 -0800 From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Keith Moore Date: Mon, 7 Feb 2011 10:42:16 -0800 Thread-Topic: [v6ops] [Fwd: I-DAction:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] Thread-Index: AcvG9fenRrK6S76oTnOTuIryiATpmQAACZ/g Message-ID: References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0AB A1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4AC EFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl > <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF7 4E@free.fr> <4D4C3E51.8070503@brightok.net><3E3F1DEC-161F-42E1-9210-907F23F 43A12@gmail.com><4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net><4D4C837F.8020306@gmail.com><4D4FFAA9.2040306@brightok.net><89F284E2-934F -4B9C-AB66-AD836F43BC51@network-heretics.com><4D4FFF68.2000403@brightok.net ><3AC337CC-1230-4E4B-A4D2-2E25FD832512@network-heretics.com><4D5006DB.30402 09@brightok.net><0EA7E738-697C-4AC9-91CD-682BCC8D7FFE@network-heretics.com> <4B12A44C-5024-409B-8827-9911E3FFA6EF@network-heretics.com> <05DA4FE8-9DDA-40B9-B7AB-DA5DC9E6CF96@free.fr> In-Reply-To: <05DA4FE8-9DDA-40B9-B7AB-DA5DC9E6CF96@free.fr> 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: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-DAction:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:42:16 -0000 > - 6rd provides "real" native IPv6 addresses. Not quite *real*, because the 6rd address still includes an embedded IPv4 address - I presume that is why you put the quotes around "real"? Thanks - Fred fred.l.templin@boeing.com= From Fred.L.Templin@boeing.com Mon Feb 7 10:46:14 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 010F73A6D81 for ; Mon, 7 Feb 2011 10:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv0tSpi9RTxa for ; Mon, 7 Feb 2011 10:46:12 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id E08403A6E7D for ; Mon, 7 Feb 2011 10:46:09 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p17IkB7j017618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Feb 2011 10:46:12 -0800 (PST) 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 p17IkBsH012890; Mon, 7 Feb 2011 10:46:11 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p17IkAaA012881 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 7 Feb 2011 10:46:11 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Mon, 7 Feb 2011 10:46:10 -0800 From: "Templin, Fred L" To: Daniel Roesen , "v6ops@ietf.org" Date: Mon, 7 Feb 2011 10:46:09 -0800 Thread-Topic: [v6ops] Fwd: New VersionNotificationfor draft-troan-v6ops-6to4-to-historic-00 Thread-Index: AcvG9joLFXLKsTMJSnCV1B52JVsPrwAAJ1PA Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com><20110207175624. GA929@srv03.cluenet.de> <20110207183748.GB3331@srv03.cluenet.de> In-Reply-To: <20110207183748.GB3331@srv03.cluenet.de> 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] Fwd: New VersionNotificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:46:14 -0000 Hi Daniel, - Although a CPE would be a logical platform for IRON client functionality, there is no requirement to touch the CPEs. See also the other advantages I listed to Ted a few messages back, and let me know if you would like me to expand on them. - IRON is not a short- nor even mid-term solution; it is a once-and-done solution for the long term. Thanks - Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Daniel Roesen > Sent: Monday, February 07, 2011 10:38 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] Fwd: New VersionNotificationfor=20 > draft-troan-v6ops-6to4-to-historic-00 >=20 > On Mon, Feb 07, 2011 at 10:04:08AM -0800, Templin, Fred L wrote: > > > 6RD. > >=20 > > Why not something better? Why not IRON: >=20 > Find a significant base of cheap CPE vendors supporting it, and an > ecosystem for the ISP-side systems. All ready to deploy=20 > within the next > few months in ~production quality, CPEs shipping in the=20 > numbers with many > zeros (6+), and an residential customer market compatible price point > (no, Cisco ISRs don't fit that). >=20 > All that for something that is needed for only a very few years until > access networks are dual-stack ready. >=20 > Too late. >=20 > Best regards, > Daniel >=20 > --=20 > CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From moore@network-heretics.com Mon Feb 7 10:54:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87BD03A6E7D for ; Mon, 7 Feb 2011 10:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LdsI88aPNmy for ; Mon, 7 Feb 2011 10:54:44 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 6B80B3A6D81 for ; Mon, 7 Feb 2011 10:54:40 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmWET-0003Ty-Qe; Mon, 07 Feb 2011 13:54:43 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Mon, 7 Feb 2011 13:54:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0AB A1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4AC EFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl > <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF7 4E@free.fr> <4D4C3E51.8070503@brightok.net><3E3F1DEC-161F-42E1-9210-907F23F 43A12@gmail.com><4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net><4D4C837F.8020306@gmail.com><4D4FFAA9.2040306@brightok.net><89F284E2-934F -4B9C-AB66-AD836F43BC51@network-heretics.com><4D4FFF68.2000403@brightok.net ><3AC337CC-1230-4E4B-A4D2-2E25FD832512@network-heretics.com><4D5006DB.30402 09@brightok.net><0EA7E738-697C-4AC9-91CD-682BCC8D7FFE@network-heretics.com> <4B12A44C-5024-409B-8827-9911E3FFA6EF@network-heretics.com> <05DA4FE8-9DDA-40B9-B7AB-DA5DC9E6CF96@free.fr> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940e4ded02c2a1b393edcd43c7a79e6aaf5350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-DAction:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:54:45 -0000 On Feb 7, 2011, at 1:42 PM, Templin, Fred L wrote: >> - 6rd provides "real" native IPv6 addresses. >=20 > Not quite *real*, because the 6rd address still > includes an embedded IPv4 address - I presume > that is why you put the quotes around "real"? for my purposes it doesn't matter how the bits of the address are = determined. what matters is that the v6 packets using those addresses = can be sent over the public v6 network, and the hosts using those = addresses are reliably reachable (modulo explicit security policy, of = course) from the public v6 network. Keith From gert@space.net Mon Feb 7 10:55:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9B53A6E7C for ; Mon, 7 Feb 2011 10:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA8x2SMUIeCK for ; Mon, 7 Feb 2011 10:55:44 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by core3.amsl.com (Postfix) with ESMTP id DEA0B3A6D81 for ; Mon, 7 Feb 2011 10:55:43 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 1A0B3F8156 for ; Mon, 7 Feb 2011 19:55:48 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id F3023F8160 for ; Mon, 7 Feb 2011 19:55:47 +0100 (CET) Received: (qmail 35391 invoked by uid 1007); 7 Feb 2011 19:55:47 +0100 Date: Mon, 7 Feb 2011 19:55:47 +0100 From: Gert Doering To: Keith Moore Message-ID: <20110207185547.GA44800@Space.Net> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vIXBmblrD40XNCy4" Content-Disposition: inline In-Reply-To: <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:55:45 -0000 --vIXBmblrD40XNCy4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Feb 07, 2011 at 01:30:42PM -0500, Keith Moore wrote: > so fix the anycast relays. =20 Which one, exactly? If you can't answer that question, it cannot be done. > it's easier to do that than to get either 6rd or pure v6 everywhere. There's no way to fix every single anycast relay out there, and since you can't pick which relay you want to use, some paths will always broken. technology fail. Gert Doering -- NetMaster --=20 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 --vIXBmblrD40XNCy4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQCVAwUBTVBAM6kuBuNlUUl1AQJ/xgP+Jcu8iVgQSEtahVZVDqCzCFqYz8rEoJIm y4Figzx9LYDrg+PJk7mUCX0PTAEJQkeZdosXSPxfeVKMpPnLoZXf4IvrvVDVxrek CM1iMVe4BQabTGT51X68hr06QIxtmeGrXwH8yZEZz3P0ZreDOpQJ7rt0162nidsA 1svyMZHyYDg= =IWbX -----END PGP SIGNATURE----- --vIXBmblrD40XNCy4-- From jbates@brightok.net Mon Feb 7 11:04:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13753A6E8C for ; Mon, 7 Feb 2011 11:04:49 -0800 (PST) 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.087, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2KH4+83Ho37 for ; Mon, 7 Feb 2011 11:04:48 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 88D4C3A6E8F for ; Mon, 7 Feb 2011 11:04:48 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17J4n1q022110; Mon, 7 Feb 2011 13:04:50 -0600 (CST) Message-ID: <4D504251.4050101@brightok.net> Date: Mon, 07 Feb 2011 13:04:49 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gert Doering References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> In-Reply-To: <20110207185547.GA44800@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:04:49 -0000 On 2/7/2011 12:55 PM, Gert Doering wrote: > There's no way to fix every single anycast relay out there, and since > you can't pick which relay you want to use, some paths will always > broken. technology fail. Which is why 6to4 anycast really only semi-works if you use NPTv6. It's by no means any more desirable than NAT444, but it does allow limited IPv6 connectivity where IPv4 connectivity doesn't exist. Jack From moore@network-heretics.com Mon Feb 7 11:05:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE43E3A6E90 for ; Mon, 7 Feb 2011 11:05:25 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdYZth+jEna7 for ; Mon, 7 Feb 2011 11:05:25 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id E7C7E3A6E89 for ; Mon, 7 Feb 2011 11:05:24 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmWOt-000683-FU; Mon, 07 Feb 2011 14:05:28 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110207185547.GA44800@Space.Net> Date: Mon, 7 Feb 2011 14:05:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940a09595aa16ecca515f55c20db339e31c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:05:26 -0000 On Feb 7, 2011, at 1:55 PM, Gert Doering wrote: > On Mon, Feb 07, 2011 at 01:30:42PM -0500, Keith Moore wrote: >> so fix the anycast relays. =20 >=20 > Which one, exactly? If you can't answer that question, it cannot be = done. that's the problem with anycast in general, isn't it? >> it's easier to do that than to get either 6rd or pure v6 everywhere. >=20 > There's no way to fix every single anycast relay out there, and since > you can't pick which relay you want to use, some paths will always > broken.=20 doesn't follow. what does follow is that there needs to be a way to = identify broken anycast relays and either get them fixed or filter them = from routing advertisements. Keith= From fred@cisco.com Mon Feb 7 11:12:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4152C3A6E5C for ; Mon, 7 Feb 2011 11:12:02 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3eQr-M87ugw for ; Mon, 7 Feb 2011 11:11:56 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E46923A6E4E for ; Mon, 7 Feb 2011 11:11:53 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACrTT02rR7Hu/2dsb2JhbAClNXOeSpsMhVoEhHqGbYMu Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 07 Feb 2011 19:11:58 +0000 Received: from Freds-Computer.local (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p17JBrb5003478; Mon, 7 Feb 2011 19:11:58 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 07 Feb 2011 11:11:58 -0800 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 07 Feb 2011 11:11:58 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Mon, 7 Feb 2011 11:11:43 -0800 Message-Id: <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:12:02 -0000 On Feb 7, 2011, at 10:04 AM, Templin, Fred L wrote: > Why not something better? Why not IRON: "Better" is a value judgement, a comparison of a proposed solution with = a set of requirements, and is often somewhat in the eye of the beholder. I think it would be fair to say that the objective of v6ops is to = deploy, operate, and maintain a ubiquitous IPv6 network comparable to = the IPv4 network of today and independent of any underlying = infrastructure. There may well be underlying infrastructure of various = kinds - ATM, MPLS, various WAN technologies, or "Ethernet" in whatever = form it may appear at the moment. However, the networks that the = operators on this list operate are not networks in which one expects = hosts to dynamically place circuits on an infrastructure of a different = kind to provide service, but to operate as a ubiquitous and stable = service.=20 It may be fair to ask each type of technology to describe its = relationship to that kind of service, and to carefully consider the = operational implications of running it. That's where Ole is coming from = in suggesting that RFC 3056 be retired; it depends on an underlying = infrastructure (IPv4 addressing and anycast servers), and has been a = source of problems for ISPs trying to deploy native IPv6 service as = noted in RFCs 3964 and 4472, and in the drafts = draft-ietf-v6ops-tunnel-loops, = draft-ietf-v6ops-tunnel-security-concerns, = draft-kuarsingh-v6ops-6to4-provider-managed-tunnel, and = draft-vandevelde-v6ops-harmful-tunnels. That is also at least in part = where questions of other overlay networks like Teredo come in. If I can summarize Keith's concern with 6rd, it is not that it doesn't = deploy an IPv6-capable service; it is that the service has a smaller = Path MTU than the native MTU of links he uses, often has a broken PMTU = implementation due to ICMPv6 filtering, and is not native. If I can = summarize the views of those using it (such as a Dutch provider I spoke = with Wednesday in London), it's not that they don't want or expect to = deploy a native IPv6 service, it's that they want to deploy an IPv6 = service now and have infrastructure that they can't immediately upgrade = (such as, in the Dutch case I mentioned, a service network that they = have to use that is IPv4-only for the foreseeable future). Similar exchanges can be described around dIVI, 4rd, and ds-lite. = Fundamentally, if my bread and butter today is IPv4 and my shiny new = IPv6 network will in the nature of the case require some time to harden, = why would I disrupt my bread and butter to deploy the new, and while = doing so make my present business model dependent on the = not-yet-hardened network? They are very reasonable ways to remove IPv4 = from a dual stack network, but from the perspective of risk an odd way = to deploy the IPv6 network. If you want to make the case that IRON is "better" than something else, = I think the thing to do is write the applicability statement. The = networks on this list operate as a ubiquitous and stable service = comparable to the present IPv4 network and independent of any underlying = infrastructure; anything else needs to help them move toward that goal, = and needs by nature to be effortlessly removed from the network as = native IPv6 deployment settles in. What is the applicability of IRON to = such a network?= From moore@network-heretics.com Mon Feb 7 11:12:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61263A6E5C for ; Mon, 7 Feb 2011 11:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tthKGKeLUeok for ; Mon, 7 Feb 2011 11:12:48 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id F21943A6E3E for ; Mon, 7 Feb 2011 11:12:47 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmWW2-0003pm-JJ; Mon, 07 Feb 2011 14:12:51 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-28-971182070 From: Keith Moore In-Reply-To: <4D504251.4050101@brightok.net> Date: Mon, 7 Feb 2011 14:12:41 -0500 Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9404a6c31709f1e416ba7c6ed1ce137f08e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:12:48 -0000 --Apple-Mail-28-971182070 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 7, 2011, at 2:04 PM, Jack Bates wrote: > On 2/7/2011 12:55 PM, Gert Doering wrote: >> There's no way to fix every single anycast relay out there, and since >> you can't pick which relay you want to use, some paths will always >> broken. technology fail. >=20 > Which is why 6to4 anycast really only semi-works if you use NPTv6. = It's by no means any more desirable than NAT444, but it does allow = limited IPv6 connectivity where IPv4 connectivity doesn't exist. NPTv6 is completely irrelevant here. And whether 6to4 is more = desirable than NAT444, or vice versa, depends on what your specific = needs are at the moment. Really it's a false dichotomy. Users need = both v6 and v4 connectivity at the same time, and they need both of them = to work from everywhere (or at least, from any connection mechanism that = we currently use to support mobility).=20 Keith --Apple-Mail-28-971182070 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = 2/7/2011 12:55 PM, Gert Doering wrote:
There's no way to fix every single anycast relay out = there, and since
you can't = pick which relay you want to use, some paths will = always
broken. =  technology fail.

Which is why 6to4 anycast = really only semi-works if you use NPTv6. It's by no means any more = desirable than NAT444, but it does allow limited IPv6 connectivity where = IPv4 connectivity doesn't exist.

NPTv= 6 is completely irrelevant here.   And whether 6to4 is more = desirable than NAT444, or vice versa, depends on what your specific = needs are at the moment.   Really it's a false dichotomy. =  Users need both v6 and v4 connectivity at the same time, and they = need both of them to work from everywhere (or at least, from any = connection mechanism that we currently use to support = mobility). 

Keith

= --Apple-Mail-28-971182070-- From fred@cisco.com Mon Feb 7 11:15:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321BF3A6E83 for ; Mon, 7 Feb 2011 11:15:59 -0800 (PST) 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, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkT5Qvpwb-y2 for ; Mon, 7 Feb 2011 11:15:58 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 810083A69AF for ; Mon, 7 Feb 2011 11:15:58 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAILTT02rR7Ht/2dsb2JhbACfSYVsc55VmwyFWgSEeoZtgy4 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 07 Feb 2011 19:16:03 +0000 Received: from Freds-Computer.local (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p17JFwIc002366; Mon, 7 Feb 2011 19:16:03 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 07 Feb 2011 11:16:03 -0800 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 07 Feb 2011 11:16:03 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> Date: Mon, 7 Feb 2011 11:15:49 -0800 Message-Id: <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:15:59 -0000 On Feb 7, 2011, at 9:57 AM, Keith Moore wrote: > 6rd is great for ISPs. It doesn't solve the problem for individual = users. The folks in this working group are mostly ISPs, and are mostly working = on the problems of ISPs... I recognize the issues of individual users; ipv6.juniper.org is = essentially unusable from my home because of path MTU issues, to name = one. At some point, it might be more useful to write an internet draft = describing the problems you're concerned about and help us work out = solutions or requirements for solutions, rather than simply barraging = the list with "I don't like it".= From gert@space.net Mon Feb 7 11:16:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A85AA3A6985 for ; Mon, 7 Feb 2011 11:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUwavQvbTxpP for ; Mon, 7 Feb 2011 11:16:52 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by core3.amsl.com (Postfix) with ESMTP id B96163A6E8E for ; Mon, 7 Feb 2011 11:16:51 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 0192DF8156 for ; Mon, 7 Feb 2011 20:16:56 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id E00E9F816A for ; Mon, 7 Feb 2011 20:16:55 +0100 (CET) Received: (qmail 40964 invoked by uid 1007); 7 Feb 2011 20:16:55 +0100 Date: Mon, 7 Feb 2011 20:16:55 +0100 From: Gert Doering To: Keith Moore Message-ID: <20110207191655.GC44800@Space.Net> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1IOPqZ3f1xe/JZlz" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:16:53 -0000 --1IOPqZ3f1xe/JZlz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Feb 07, 2011 at 02:05:10PM -0500, Keith Moore wrote: > > On Mon, Feb 07, 2011 at 01:30:42PM -0500, Keith Moore wrote: > >> so fix the anycast relays. =20 > > Which one, exactly? If you can't answer that question, it cannot be do= ne. > that's the problem with anycast in general, isn't it? With anycast of the sort deployed here, with no way the client can failover to a different relay if the route back from the server is=20 broken, yes. Other sorts of anycast provide fallback mechanisms (like "multiple=20 different anycast clouds" and "it's up to the client ONLY to choose=20 a given 'anycast thing'"). > >> it's easier to do that than to get either 6rd or pure v6 everywhere. > >=20 > > There's no way to fix every single anycast relay out there, and since > > you can't pick which relay you want to use, some paths will always > > broken.=20 >=20 > doesn't follow. what does follow is that there needs to be a way=20 > to identify broken anycast relays and either get them fixed or filter=20 > them from routing advertisements. And how exactly are you going to do that? You type "www.importantsite.com"= =20 into your browser, the packet leaves via the 6to4 relay nearest to you=20 (which is nice, dandy, and working) and you do not get a response back. =20 Or you get a response with horrible latency, and packet loss. Responsible relay operators are not the problem here. (6to4 between consenting endpoints, both on 6to4 addresses, with no relays in between, is a nice hack. The anycast relays in theory also are a very nice thing. Experience over the last 5 or so years shows that the practical side of things isn't - and now 6to4 is used by hosting providers to actually delay their IPv6 rollout "due to breakage". This is BAD.) Gert Doering -- NetMaster --=20 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 --1IOPqZ3f1xe/JZlz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQCVAwUBTVBFJ6kuBuNlUUl1AQIonAP7B8ZuwB5gOAMPnC9wv/6HzS30lUDehvK+ DFigXYBzYIkW7+3ul4G88rLEDISdBhwoWYsFLi/VJBN19BXGzxX9ey78k5CuQktV xOsGq18T7CU5DfzKHkPbouKVqh2tcXQlkT+G/Qom0oOkixFXzdmGwRaBYHuvbmWD 275ItGuG1Sc= =1Jia -----END PGP SIGNATURE----- --1IOPqZ3f1xe/JZlz-- From fred@cisco.com Mon Feb 7 11:20:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7078E3A6E81 for ; Mon, 7 Feb 2011 11:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu3gjNal8Vas for ; Mon, 7 Feb 2011 11:20:41 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 58EA93A6985 for ; Mon, 7 Feb 2011 11:20:41 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHXUT02rRN+K/2dsb2JhbAClNHOeYZsMhVoEhHqGbYMu Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 07 Feb 2011 19:20:46 +0000 Received: from Freds-Computer.local (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p17JKfsV026455; Mon, 7 Feb 2011 19:20:45 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 07 Feb 2011 11:20:46 -0800 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 07 Feb 2011 11:20:46 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D504251.4050101@brightok.net> Date: Mon, 7 Feb 2011 11:20:31 -0800 Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:20:42 -0000 On Feb 7, 2011, at 11:04 AM, Jack Bates wrote: > On 2/7/2011 12:55 PM, Gert Doering wrote: >> There's no way to fix every single anycast relay out there, and since >> you can't pick which relay you want to use, some paths will always >> broken. technology fail. >=20 > Which is why 6to4 anycast really only semi-works if you use NPTv6. = It's by no means any more desirable than NAT444, but it does allow = limited IPv6 connectivity where IPv4 connectivity doesn't exist. I'm very confused. If you are using NPTv6, you have native IPv6 service. = If you have native IPv6 service, why on earth would you be using 6to4?= From jbates@brightok.net Mon Feb 7 11:23:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DAE23A6E5E for ; Mon, 7 Feb 2011 11:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.184 X-Spam-Level: X-Spam-Status: No, score=-3.184 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-RuVeCYrWIH for ; Mon, 7 Feb 2011 11:23:32 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 20CCA3A6E51 for ; Mon, 7 Feb 2011 11:23:32 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17JNZcb026883; Mon, 7 Feb 2011 13:23:35 -0600 (CST) Message-ID: <4D5046B7.7090305@brightok.net> Date: Mon, 07 Feb 2011 13:23:35 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:23:33 -0000 On 2/7/2011 1:12 PM, Keith Moore wrote: > NPTv6 is completely irrelevant here. And whether 6to4 is more > desirable than NAT444, or vice versa, depends on what your specific > needs are at the moment. Really it's a false dichotomy. Users need > both v6 and v4 connectivity at the same time, and they need both of them > to work from everywhere (or at least, from any connection mechanism that > we currently use to support mobility). > No. NPTv6 combined with 6to4 anycast removes the return anycast server requirement. The problem is, it also does NAT66. I agree with your sentiments of what it should be. If we'd actually started the mad rush to IPv6 a decade ago, we'd be happily playing on our IPv6 networks and not have had any issues. 6to4 wasn't designed with the mindset that we'd actually run out of IPv4 before starting the IPv6 migrations. IPv4 peer to peer will break for some/many customers. CGN is coming. We waited too long. 6to4 peer to peer capabilities will break with CGN, even using anycast (as with CGN, 6to4 anycast requires NAT66). While ISPs are now pushing vendors for implementations at the last minute, many corporations still believe there will be IPv4 forever and IPv6 is unnecessary. Jack From moore@network-heretics.com Mon Feb 7 11:24:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E9A83A6EB1 for ; Mon, 7 Feb 2011 11:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mzawdw5o0rl6 for ; Mon, 7 Feb 2011 11:23:59 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 704FA3A6EAF for ; Mon, 7 Feb 2011 11:23:59 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmWgt-0000UT-Ac; Mon, 07 Feb 2011 14:24:03 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> Date: Mon, 7 Feb 2011 14:23:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940a698cb68b2608868bf747ef04741e180350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:24:00 -0000 On Feb 7, 2011, at 2:15 PM, Fred Baker wrote: > On Feb 7, 2011, at 9:57 AM, Keith Moore wrote: >=20 >> 6rd is great for ISPs. It doesn't solve the problem for individual = users. >=20 > The folks in this working group are mostly ISPs, and are mostly = working on the problems of ISPs... Well, that's a problem, isn't it? Not that there's a ready = solution...but it does help to acknowledge the limited view of this = group and the potential consequences from that. > I recognize the issues of individual users; ipv6.juniper.org is = essentially unusable from my home because of path MTU issues, to name = one. At some point, it might be more useful to write an internet draft = describing the problems you're concerned about and help us work out = solutions or requirements for solutions, rather than simply barraging = the list with "I don't like it". Since when were arguments of the form "this will break things that = people need" out of scope? Also it seems like writing an I-D is not a good substitute for = confronting the differences head on. All too often, I-Ds have become a = way to let people talk past each other and avoid trying to resolve the = tussles.=20 Though I don't have an objection to writing an I-D once the issues = become a bit clearer. Keith p.s. have you tried path MTU clamping on your home router? From jbates@brightok.net Mon Feb 7 11:26:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3483A6E51 for ; Mon, 7 Feb 2011 11:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMoQAKhCVKVl for ; Mon, 7 Feb 2011 11:26:04 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 6E3B93A6E5E for ; Mon, 7 Feb 2011 11:26:04 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p17JQ5cd027136; Mon, 7 Feb 2011 13:26:05 -0600 (CST) Message-ID: <4D50474D.3030406@brightok.net> Date: Mon, 07 Feb 2011 13:26:05 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:26:05 -0000 On 2/7/2011 1:20 PM, Fred Baker wrote: > > I'm very confused. If you are using NPTv6, you have native IPv6 > service. If you have native IPv6 service, why on earth would you be > using 6to4? I can NAT66 from 2002:: prefixes to my native prefixes (I have native IPv6 at all ISP 6to4 relays). I'd be using 6to4 in any scenario where a customer did not support any other IPv6 mechanism (ie, no 6rd support, no native support). Jack From cb.list6@gmail.com Mon Feb 7 11:29:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2C5F3A6E83 for ; Mon, 7 Feb 2011 11:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1ev5vBTmbYO for ; Mon, 7 Feb 2011 11:29:09 -0800 (PST) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 084113A6E51 for ; Mon, 7 Feb 2011 11:29:08 -0800 (PST) Received: by pxi6 with SMTP id 6so1222202pxi.31 for ; Mon, 07 Feb 2011 11:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RgAGwynIQl8BzsebL8WAFVn/tx4VSrydS3TYpTMO/KM=; b=Jkmr5iCgK/dZ3Eqmh1ZIKE/bZX+7vumkhtog+xaOUirzhmFX8e2X4tSMV4pLgpZWM5 wBJoDUQ3VfI9crjfIkJZJnzqy/1UBgEd3Q1bGMzUZ6UI+1TaS+N7wNiiahxBcCXyeS5L /hM0eIeqPki/VsN8Xtac5YvdCPjw99vX0uzhw= 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=LqYz6M2ktdD2b1hhbdGMNoz48a2Rcmhb81nMh9wrnEVHyEFzsSMG5vtl2XgLb3ytgf heqM8870iFWmBK3xJANp5Qa5Aos0XsCiedBgrK+sjXP8kZD1YPzvEa3DF9C7cVzF8hF6 QXvPyGp0y9QveCLtQcq1p5B82pmV8Hxei8eJ4= MIME-Version: 1.0 Received: by 10.142.44.17 with SMTP id r17mr7336190wfr.223.1297106953600; Mon, 07 Feb 2011 11:29:13 -0800 (PST) Received: by 10.142.178.2 with HTTP; Mon, 7 Feb 2011 11:29:13 -0800 (PST) In-Reply-To: <20110207182427.GX44800@Space.Net> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> Date: Mon, 7 Feb 2011 11:29:13 -0800 Message-ID: From: Cameron Byrne To: Gert Doering Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:29:10 -0000 On Mon, Feb 7, 2011 at 10:24 AM, Gert Doering wrote: > Hi, > > On Mon, Feb 07, 2011 at 12:57:49PM -0500, Keith Moore wrote: >> 6rd is great for ISPs. =A0It doesn't solve the problem for individual us= ers. > > Neither does 6to4 with badly deployed anycast relays. > +1 I already null route the anycast address because it cause a mess in my CGN/NAT tables ... since i use bogon space to my users they think 6to4 might work. Yes... I am the face of the future internet. > Gert Doering > =A0 =A0 =A0 =A0-- NetMaster > -- > did you enable IPv6 on something today...? > > SpaceNet AG =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vorstand: Seba= stian v. Bomhard > Joseph-Dollinger-Bogen 14 =A0 =A0 =A0 =A0 =A0Aufsichtsratsvors.: A. Grund= ner-Culemann > D-80807 Muenchen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 HRB: 136055 (AG Muen= chen) > Tel: +49 (89) 32356-444 =A0 =A0 =A0 =A0 =A0 =A0USt-IdNr.: DE813185279 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From jbates@brightok.net Mon Feb 7 11:33:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF7A3A6E51 for ; Mon, 7 Feb 2011 11:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Df3LkpHKErY for ; Mon, 7 Feb 2011 11:33:33 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 504C43A6D40 for ; Mon, 7 Feb 2011 11:33:33 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17JXZXj029523; Mon, 7 Feb 2011 13:33:35 -0600 (CST) Message-ID: <4D50490F.4070500@brightok.net> Date: Mon, 07 Feb 2011 13:33:35 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:33:34 -0000 On 2/7/2011 1:23 PM, Keith Moore wrote: > Since when were arguments of the form "this will break things that > people need" out of scope? > When it's already been recognized that those things will break and no one is providing a good solution, or people ignore the already existing solutions. Given implementation time frames, the best v6ops can hope for is to clarify on current problems and currently implemented available solutions to make things as interoperable as possible; accepting that there are some problems we just can't fix (as some are IPv4 problems which happen to effect some of the IPv6 transition tools). Jack From moore@network-heretics.com Mon Feb 7 11:34:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 142FB3A6E83 for ; Mon, 7 Feb 2011 11:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMikTUTAyd+Q for ; Mon, 7 Feb 2011 11:34:09 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 127DA3A6E5E for ; Mon, 7 Feb 2011 11:34:09 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmWqg-0001ao-1q; Mon, 07 Feb 2011 14:34:11 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110207191655.GC44800@Space.Net> Date: Mon, 7 Feb 2011 14:33:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <20110207191655.GC44800@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94053cda030c2c34439f9815fabd092872c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:34:10 -0000 On Feb 7, 2011, at 2:16 PM, Gert Doering wrote: > Hi, >=20 > On Mon, Feb 07, 2011 at 02:05:10PM -0500, Keith Moore wrote: >>> On Mon, Feb 07, 2011 at 01:30:42PM -0500, Keith Moore wrote: >>>> so fix the anycast relays. =20 >>> Which one, exactly? If you can't answer that question, it cannot be = done. >> that's the problem with anycast in general, isn't it? >=20 > With anycast of the sort deployed here, with no way the client can > failover to a different relay if the route back from the server is=20 > broken, yes. That's part of the problem. The other part is that when a bunch of = things all answer to the same address (and/or source things from the = same address), it's more difficult to identify the ones that are broken = and hold them accountable. Not impossible, but more difficult. Ideally hosts would be able to route around broken relays. Maybe such a = mechanism can be devised. But if there were a way to track down broken = relays and neutralize them, I think that would be sufficient. =20 (Note also that 6to4 is separate from anycast relays. If there were a = means to keep 6to4 working but improve on the current anycast relays as = a way to gateway between native and 6to4, it would be worth considering. = A different kind of relay might still be easier to deploy than 6rd, = configured tunnels, or some other proposal which would replace 6to4 = entirely) >>>> it's easier to do that than to get either 6rd or pure v6 = everywhere. >>>=20 >>> There's no way to fix every single anycast relay out there, and = since >>> you can't pick which relay you want to use, some paths will always >>> broken.=20 >>=20 >> doesn't follow. what does follow is that there needs to be a way=20 >> to identify broken anycast relays and either get them fixed or filter=20= >> them from routing advertisements. >=20 > And how exactly are you going to do that? You type = "www.importantsite.com"=20 > into your browser, the packet leaves via the 6to4 relay nearest to you=20= > (which is nice, dandy, and working) and you do not get a response = back. =20 > Or you get a response with horrible latency, and packet loss. I don't have an immediate answer. Whatever the solution is, it's not = likely to be something that end users can use directly. Which is of no = great consequence, as users are in a lousy position to get network = problems fixed anyway. Brian's draft identifies several failure modes, so it's important to = test for each of those. > Responsible relay operators are not the problem here. >=20 > (6to4 between consenting endpoints, both on 6to4 addresses, with no > relays in between, is a nice hack. The anycast relays in theory also > are a very nice thing. Experience over the last 5 or so years shows > that the practical side of things isn't - and now 6to4 is used by > hosting providers to actually delay their IPv6 rollout "due to = breakage". > This is BAD.) Certainly agree that it's BAD and needs to be fixed. But let's try not = to overreact. Keith From jbates@brightok.net Mon Feb 7 11:34:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E06D3A6E90 for ; Mon, 7 Feb 2011 11:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhwdT7JBdQps for ; Mon, 7 Feb 2011 11:34:43 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 64E983A6E5E for ; Mon, 7 Feb 2011 11:34:43 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17JYjRS029822; Mon, 7 Feb 2011 13:34:46 -0600 (CST) Message-ID: <4D504956.1050209@brightok.net> Date: Mon, 07 Feb 2011 13:34:46 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cameron Byrne References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:34:44 -0000 On 2/7/2011 1:29 PM, Cameron Byrne wrote: > I already null route the anycast address because it cause a mess in my > CGN/NAT tables ... since i use bogon space to my users they think > 6to4 might work. Do you have NAT66 support yet that you could possibly deploy on anycast relays to convert the 2002:: addresses to your own IPv6 addresses? Jack From cb.list6@gmail.com Mon Feb 7 11:44:14 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8233A6E83 for ; Mon, 7 Feb 2011 11:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsW8voDKYm6W for ; Mon, 7 Feb 2011 11:44:13 -0800 (PST) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 66B6A3A6E80 for ; Mon, 7 Feb 2011 11:44:13 -0800 (PST) Received: by pxi6 with SMTP id 6so1225794pxi.31 for ; Mon, 07 Feb 2011 11:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7h5UXpBbNwWJ/yTBXzB1cK73yT7aH4L5CbBfq3Y1NaA=; b=qnznx9YEZTMAGqR55Lv8SONQyGkWYBMJVyOBuYG2xP0rnR0LAKQXos2DFP8EtehPuN Ju6UnYFqprM47NIHKJAxZOpINs1cWlpBLemNeP4g4rc9eFPi/2czTSItxucmFWKQSsI5 XmqvbEifE/MiTt9KbywYAkdGjrDHJkGwuYcWs= 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=S20TuIuo8xZ7gLavHVX9Lm2ZlB3nHcSFHLZNekYoeRLa02s81qtXGORveQR2/jYkbR PNPFX6YY3u6zCT9PR1lAjQ6CPbGPPRo+kUQKHfIC0sj6QVUYlIsPbWlf1AfbweGPC2Hu 0P/DNVomEYEn2TrtT9mKsyiePTgtO8npyCxwo= MIME-Version: 1.0 Received: by 10.142.144.4 with SMTP id r4mr15985487wfd.76.1297107858154; Mon, 07 Feb 2011 11:44:18 -0800 (PST) Received: by 10.142.178.2 with HTTP; Mon, 7 Feb 2011 11:44:18 -0800 (PST) In-Reply-To: <4D504956.1050209@brightok.net> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> Date: Mon, 7 Feb 2011 11:44:18 -0800 Message-ID: From: Cameron Byrne To: Jack Bates Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:44:14 -0000 On Mon, Feb 7, 2011 at 11:34 AM, Jack Bates wrote: > > > On 2/7/2011 1:29 PM, Cameron Byrne wrote: >> >> I already null route the anycast address because it cause a mess in my >> CGN/NAT tables ... since i use bogon space to =A0my users they think >> 6to4 might work. > > Do you have NAT66 support yet that you could possibly deploy on anycast > relays to convert the 2002:: addresses to your own IPv6 addresses? > Nope, and not interested since customers don't care about this 6to4 service. The only people that care are network admins that have to deal when it breaks the user or the network. Customers care that facebook and google and pandora work ... they are generally not interested in these transport messes, and that is why IPv6 is still not deployed in MOST place. For customers that know what IPv6 is, i have a solution for them, native IPv6 access, 200 million+ covered people in the USA. http://groups.google.com/group/tmoipv6beta The days of figuring out transition mechanisms is over. IPv4 is really exhausted, people need to think about things that are real and production scale. 6to4 is neither, its more of a hobby than an infrastructure and the major content players cite 6to4 as a roadblock. Nobody's fault, just the way it is. Your efforts are better spent on rolling out native IPv6 now than trying to fix something that was built on some pretty naive assumptions (20-20 hind sight), like that fact that BOGONs would not be used and IPv4 at the end user would be available in the "IPv4 end-times". From brian.e.carpenter@gmail.com Mon Feb 7 12:17:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0111B3A69E0 for ; Mon, 7 Feb 2011 12:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dP0jVMIpnTyP for ; Mon, 7 Feb 2011 12:17:15 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B80E23A6921 for ; Mon, 7 Feb 2011 12:17:14 -0800 (PST) Received: by bwz12 with SMTP id 12so5895363bwz.31 for ; Mon, 07 Feb 2011 12:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GaJMtnY0qzKE26CByF57RCzQFBFdVDb+5RN58WOdyk0=; b=XjVLFtOhYA/4GnBOt2O/s+iggg/7Rz3nwCwwe5FLBOjKUMh8ogVjY3RstmawPNPiVi sRT4Tukx0cZVlLNBnm1h9nEbVkt/ESYtKjKXLWLnUkHfkLPqYYOstALfIq5km6S/+Qka zmkjOTpnWIwJHJEnBm7b7rWrqRaHnnZdm3UQk= 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=KCir69f0AQixoa4hfSsS4u35KoXljL7F6XVs+WuXcAeXk1C48r8+j226L/hVYvcxbN oIBKVv7A5VlEfFSkKb9iy0jqOhtMfmJp+BhqzS8oGVR060qT7CLyK7iFqBCQ17LjlrGa CYVkfmUV10ea5i6a1LOyIjfzxwoGwXu53YLvQ= Received: by 10.204.98.75 with SMTP id p11mr5872943bkn.12.1297109838280; Mon, 07 Feb 2011 12:17:18 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id a17sm2287105bku.11.2011.02.07.12.17.13 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 12:17:16 -0800 (PST) Message-ID: <4D505345.8080006@gmail.com> Date: Tue, 08 Feb 2011 09:17:09 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jack Bates References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> In-Reply-To: <4D4FFAA9.2040306@brightok.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Keith Moore Subject: [v6ops] Out of scope discussion [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 20:17:16 -0000 On 2011-02-08 02:59, Jack Bates wrote: > On 2/7/2011 7:49 AM, R=C3=A9mi Despr=C3=A9s wrote: >> >> In my understanding: >> - The advice in the draft is that content-provider ISPs, and possibly >> servers themselves, have 6to4 "relay" functions. >> - What Jack suggests is that servers themselves: >> . have 6to4 "router" functions (an therefore their own 6to4 >> addresses); >> . don't advertise these 6to4 addresses >> - A better combination, in a server that has both a public IPv4 >> address and a native IPv6 address, is that: >> . The server has the 6to4 "router function" >> . In IPv6, both the native and the 6to4 addresses are advertised. >> An explanation is given in my last answer to Jack. >> >=20 > I'd argue that, >=20 > - All servers with IPv6 connectivity have the 6to4 "router function" > - If server advertises a IPv4 addresses, do NOT advertise 6to4 addresse= s > - if server does not advertise IPv4, DO advertise 6to4 address The 6to4 standard explicitly forbids advertising any prefix in 2002::/16 that is longer than /16, for reasons explained in the standard and very strongly supported by the Operations AD at that time. This proposal appears to imply a) saying it's OK to import entropy from the IPv4 routing table into the IPv6 routing table, something that we've been specifically avoiding for the last 15 years. b) implying that servers will insert multiple AAAA records in the DNS, so that they will be "multihomed" on both native and 6to4 addresses. This was never the design goal of 6to4, which was designed specificall= y to hop over IPv4-only ISPs. This thread is about a draft containing advice to operators on how to mit= igate the problems caused by Anycast 6to4 (and Teredo). If you want to talk abo= ut expanding the scope of 6to4 beyond what is envisaged by the current standards, could you all kindly start a new thread? Please? I won't be adding any proposals to expand the scope of 6to4 to my draft. Brian >=20 > Summary of my explanation: > - If IPv4 connectivity is available, clients need to use it and not 6to= 4 > addresses > - If IPv4 is not available, clients should use 6to4 direct over anycast= ing. >=20 > I'm still unsure on this last one, but I'm reasonably sure that anythin= g > which would break direct 6to4 connectivity will break using anycasting > as well (unless some NAT66 took place). >=20 >=20 > Jack >=20 From victor.kuarsingh@gmail.com Mon Feb 7 12:33:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471C23A69B4 for ; Mon, 7 Feb 2011 12:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DstPNQLBCube for ; Mon, 7 Feb 2011 12:33:10 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id CD66E3A68FA for ; Mon, 7 Feb 2011 12:33:09 -0800 (PST) Received: by gyd12 with SMTP id 12so2164307gyd.31 for ; Mon, 07 Feb 2011 12:33:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=lSHqXbPGT8rlmIihNw+Zc5zRoR56ZqDSefD3iPs4PSM=; b=dV6q9KflMLFNnUlxFXccqDQ5XsnRoBQmU4EbzNXbVGCVfMr6HtbhDubrm4I2GlY3Qu n+BMa7SDPdPWeEOkUBJOCnrltE5gWarQT7sWHntQXaDweYo/fd3SpMgOEN3uUx21zA1Z 7RcJQ5Avsx7mB3eFSuORjVo00htQPer2yfdkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; b=QYmZVTFtMT2HEvb8F0fOpyJPIblp3ba7CwArRPicJzoVS5l0EiFvfu+dvPLuUmARTW mQYr2B/k2IpzsZNx3KYfdJU+7u672CY1RcgFg9zaYvwjFpfOqVp3dEGozchACUb2jLR0 zMpaQMb1JvjnBPc0ifwXVJtkof5GicqtBi3DA= Received: by 10.91.21.32 with SMTP id y32mr19669205agi.187.1297110794167; Mon, 07 Feb 2011 12:33:14 -0800 (PST) Received: from [10.16.150.65] ([66.185.87.27]) by mx.google.com with ESMTPS id g38sm3177885yhd.9.2011.02.07.12.33.11 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 12:33:13 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 07 Feb 2011 15:39:11 -0500 From: Victor Kuarsingh To: Jack Bates , Cameron Byrne Message-ID: Thread-Topic: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 In-Reply-To: <4D504956.1050209@brightok.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 20:33:11 -0000 Jack, There is code we are now testing which implements 6to4 with NAT66. This will translate 2002::/16 to provider block. (Based draft-kuarsingh-v6ops-6to4-provider-managed-tunnel) Testing and characterization underway. We will let the group know how well this will work. Victor K On 07/02/11 2:34 PM, "Jack Bates" wrote: > > >On 2/7/2011 1:29 PM, Cameron Byrne wrote: >> I already null route the anycast address because it cause a mess in my >> CGN/NAT tables ... since i use bogon space to my users they think >> 6to4 might work. > >Do you have NAT66 support yet that you could possibly deploy on anycast >relays to convert the 2002:: addresses to your own IPv6 addresses? > > >Jack >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Feb 7 12:33:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA5D3A69E0 for ; Mon, 7 Feb 2011 12:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.296 X-Spam-Level: X-Spam-Status: No, score=-0.296 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D-kx9vxF63b for ; Mon, 7 Feb 2011 12:33:49 -0800 (PST) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id 136153A6E55 for ; Mon, 7 Feb 2011 12:33:49 -0800 (PST) Received: from 182-239-153-173.ip.adam.com.au ([182.239.153.173] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PmXmQ-0001z9-3s; Tue, 08 Feb 2011 07:03:50 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 433793B336; Tue, 8 Feb 2011 07:03:49 +1030 (CST) Date: Tue, 8 Feb 2011 07:03:48 +1030 From: Mark Smith To: Gert Doering Message-ID: <20110208070348.2fedcfea@opy.nosense.org> In-Reply-To: <20110207182807.GY44800@Space.Net> References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 20:33:50 -0000 On Mon, 7 Feb 2011 19:28:07 +0100 Gert Doering wrote: > Hi, > > On Mon, Feb 07, 2011 at 04:17:48PM +0100, Ole Troan wrote: > > I just posted the following draft suggesting that we move the 6to4 documents to historic. > > I think 3056 is harmless enough as it is, provided connectivity to > "non-6to4" IPv6 is not happening (not *at all*, since you can't control > the return path even if the outgoig relay is sane). > > 3068 is where the breakage comes from. > I struggle to believe this when people say it. I've been using 6to4 connectivity for years, and haven't had any real issues. Maybe I've mostly been lucky with the 6to4 anycast relays I've been using. On one occasion I did end up using a broken one, however I was able to identify who ran it using IPv4 traceroute and whois. I didn't even get around to emailing them, as the problem disappeared fairly quickly. On purpose I've configured the 6to4 tunnel MTU to 1472 (derived from PPPoE MTU of 1492), rather than leaving it at 1280, so that I would more likely encounter PMTU issues if there were issues with them. I don't seem to have experienced those. Fred mentioned having trouble ipv6.juniper.org (or is it ipv6.juniper.net, ipv6.juniper.org seems to be domain squatter site?) - in either case, I'm not having trouble (I've just checked to make sure I'm accessing it over IPv6, which I am, and that includes my end announcing an MSS of 1412 (1472 - 40 - 20)). The only other thing that might be mitigating any problems is that my 6to4 end-point desktop PC (i.e. this one) is directly attached to the Internet, rather than being behind a NAT or firewalling CPE. For a while I was having trouble with IPv6 not being preferred when IPv4 and IPv6 were available, however I realised that was related to source address selection and native IPv4 being preferred over tunnelled IPv6. I changed that more than a year ago and still can't seem to fault it. Sure native connectivity is far better. However, I'd be disappointed if 6to4 went away, as it has been a good option for me. Perhaps an RFC on how to operate a 6to4 relay properly might be more useful to overcome some of the issues with them that others seem to have seen. Part of that advice could be that ISPs are encouraged to operate their on 6to4 relays as soon as they get native IPv6 transit, and for them to consider the 6to4 relay another production level service, so that they consider it's availability requirements to be the same as their DNS, mail etc. As long as they do a proper job of it, I think deploying a 6to4 relay is a relatively easy first step for an ISP to start presenting some IPv6 services to their customers. Regards, Mark. > 3056 with "only used for packets going to 2002: addresses, sourced from > 2002: addresses" is useful. > > 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Mon Feb 7 12:42:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2883A6E94 for ; Mon, 7 Feb 2011 12:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKexvDK4WkGp for ; Mon, 7 Feb 2011 12:42:32 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2E1263A69C0 for ; Mon, 7 Feb 2011 12:42:31 -0800 (PST) Received: by fxm9 with SMTP id 9so5656508fxm.31 for ; Mon, 07 Feb 2011 12:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TMz7qHud2ugcdYGVeMFMDfH9TtVDtXupmB74iG90B7U=; b=c2Kbqj+ficTgKqYmzmVAUx04cMjWwHZY8HIGfCgr1A8YJam1/r8rl10cOOg88v0BAp bW2TM4Fvv/XhkwBHggtpGltEA/N4INhAB/B6qEzYwkZHfdYlSbRz4CBmGrbZ4IDTdwV2 W/cyhcnR31dmH6sjJchKVRyH/VGtmlp4ncK2I= 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=lV0+qmYwyGR65fjVwLanjP4GwfJZZxJ0SaAztDo1dtvjjOqqlpE7i+wuMXLX0+KmLl NRzmOspcI84NG63RcMMak3AyCpuUXNkEVuNIPSNBbWvYHS6+G6U7xHVDxjQC8PtKzYE0 i3wuFJxYiGo+7CVvOcAaDaujg3S3GEw3e5x6Q= Received: by 10.223.96.78 with SMTP id g14mr7966585fan.15.1297111356297; Mon, 07 Feb 2011 12:42:36 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id y3sm1406242fai.38.2011.02.07.12.42.29 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 12:42:32 -0800 (PST) Message-ID: <4D505931.3010706@gmail.com> Date: Tue, 08 Feb 2011 09:42:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Keith Moore References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <1297091215.26424.13.camel@shakira.millnert.se> <1297093176.26424.28.camel@shakira.millnert.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 20:42:33 -0000 On 2011-02-08 04:48, Keith Moore wrote: > On Feb 7, 2011, at 10:39 AM, Martin Millnert wrote: > >> On Mon, 2011-02-07 at 10:14 -0500, Keith Moore wrote: >>> On Feb 7, 2011, at 10:06 AM, Martin Millnert wrote: >>> >>>> On Mon, 2011-02-07 at 09:07 -0500, Keith Moore wrote: >>>>> It seems to me that servers which support all of (native v6, 6to4, v4) >>>>> will be more reachable than servers which support only (native v6, >>>>> v4), because there will be v6-only hosts that sit behind 6to4 routers >>>>> (each with only an external v4 connection) and those hosts will >>>>> therefore be assigned a 6to4 address but not a native v6 address. >>>> A very favorable configuration here could be the following: >>>> A ("content") server that has native v6 and v4 will benefit from >>>> sending IPv6-in-IPv4 packets back for connections arriving from >>>> 2002::/16. >>>> Adding some additional application layer glue/clue here, a host with >>>> native IPv6 and IPv4 can consider arriving 6to4-packets to be plain IPv4 >>>> when the connection is handed off to the application layer (for those >>>> that roll their own...), with clearly added benefits to the already >>>> IPv4-aware application layer. >>> I can't imagine an interpretation of this that makes any sense at all. what in the world do you mean? >>> >>> Keith >> Sorry Keith, I'll try again. >> >> First, I was just agreeing that a content server should not send packets >> towards 6to4 anycast space. >> >> Then, I tried to explain a possible implementation method for a >> dual-stacked content server: >> >> 1) A content server has native IPv6 and IPv4, eg is dual-stacked. >> 2) A TCP SYN arrives on its IPv6 interface from 2002::/16 space. >> 3) Return packets are sent as IPv6-over-IPv4 to the unicast address >> (Brian did note some brokenness here; perhaps it can be helped by using >> source address 192.88.99.1?) >> 4) When the connection is delivered to the application layer, it is >> converted into a IPv4 connection, by decoding the IPv4 address that is >> encoded in 2002::/16 as the source address. >> 5) From now on, it's just IPv4 for the applications which they should >> be fairly familiar with. >> >> Did this make more sense? > > no. it makes no sense at all to convert a 6to4 connection into an ipv4 connection. Actually, I see his point. The probability in this scenario is that the v4 path back to the client is actually better than the v6 path, but the problem is that the client believes it's using IPv6, so it will be quite alarmed if the SYN/ACK arrives back as an IPv4 packet. So it doesn't work, afaics, unless both ends contain this trick. Brian From randy@psg.com Mon Feb 7 12:47:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3D63A6EB6 for ; Mon, 7 Feb 2011 12:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFaIioA7X8k1 for ; Mon, 7 Feb 2011 12:47:00 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id CF3663A6E55 for ; Mon, 7 Feb 2011 12:46:59 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PmXzD-000JNz-0A; Mon, 07 Feb 2011 20:47:03 +0000 Date: Mon, 07 Feb 2011 12:47:02 -0800 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <4D505345.8080006@gmail.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] Out of scope discussion [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 20:47:01 -0000 > The 6to4 standard explicitly forbids advertising any prefix in > 2002::/16 that is longer than /16, for reasons explained in the > standard and very strongly supported by the Operations AD at that > time. really? > This proposal appears to imply > a) saying it's OK to import entropy from the IPv4 routing table into the > IPv6 routing table, something that we've been specifically avoiding > for the last 15 years. and other ipv6 fantasies. deaggregation is driven by st00pidity and multi-homing, neither of which seems to be decreasing. > b) implying that servers will insert multiple AAAA records in the DNS, > so that they will be "multihomed" on both native and 6to4 addresses. > This was never the design goal of 6to4, which was designed specifically > to hop over IPv4-only ISPs. we can hope 6to4 will die soon. > This thread is about a draft containing advice to operators on how to > mitigate the problems caused by Anycast 6to4 (and Teredo). If you want > to talk about expanding the scope of 6to4 beyond what is envisaged by > the current standards, could you all kindly start a new thread? i want 6to4, teredo, 6rd, ... all dead dead dead. they are damaging kludges to support pretend-v6 around lack of deployment. let the lack of deployment show. the truth shall set you free. randy From brian.e.carpenter@gmail.com Mon Feb 7 13:05:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3103A6F19 for ; Mon, 7 Feb 2011 13:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEasMfwVzDZc for ; Mon, 7 Feb 2011 13:05:15 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 2F6653A6F17 for ; Mon, 7 Feb 2011 13:05:14 -0800 (PST) Received: by bwz12 with SMTP id 12so5950866bwz.31 for ; Mon, 07 Feb 2011 13:05:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eIjbZ01lRlpK+3gq8qxyWC7L9PUU1lv5H4uqBDsE+rA=; b=NHWIgXMTTNgtvfW5oKKtZL1zMWJrDnGgwCbBgrfucTu9LVGAgjwKUy6dNA2t8nZH3p hTsv6uve/E7MNZRk0ed1FmcCflTOe/jC1shXzpiLTbch9BQ00XOe+6oKy61etH7LrCcl G5FaNwc8J75h9VtwORgulqONVm/G9GfKrEYSE= 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=ifElHnvKh1zwkrAqspYwCsFzv+Wmd9sxMeWS2dYYmmgLNPJdf+SAlVqTIO6Taf8TsI iPUGq1gDUYr03Cl8yYsb7Mul5LCIS+BL26JJaRiW9jV9h90Hy7/6qg/tYkGvbA1B5cA5 4imFocMhtrSPs3/eyA+lTymzNmIm8DgkBTPw0= Received: by 10.204.33.74 with SMTP id g10mr641256bkd.131.1297112719439; Mon, 07 Feb 2011 13:05:19 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id v1sm2315568bkt.17.2011.02.07.13.05.15 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 13:05:17 -0800 (PST) Message-ID: <4D505E87.8020706@gmail.com> Date: Tue, 08 Feb 2011 10:05:11 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Out of scope discussion [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:05:16 -0000 On 2011-02-08 09:47, Randy Bush wrote: >> The 6to4 standard explicitly forbids advertising any prefix in >> 2002::/16 that is longer than /16, for reasons explained in the >> standard and very strongly supported by the Operations AD at that >> time. > > really? That's my recollection from ngtrans WG sessions, yes. > >> This proposal appears to imply >> a) saying it's OK to import entropy from the IPv4 routing table into the >> IPv6 routing table, something that we've been specifically avoiding >> for the last 15 years. > > and other ipv6 fantasies. deaggregation is driven by st00pidity and > multi-homing, neither of which seems to be decreasing. Correct. We'll get deaggregation in v6 for that reason, but that doesn't mean we should deaggregate 2002::/16 too. > >> b) implying that servers will insert multiple AAAA records in the DNS, >> so that they will be "multihomed" on both native and 6to4 addresses. >> This was never the design goal of 6to4, which was designed specifically >> to hop over IPv4-only ISPs. > > we can hope 6to4 will die soon. > >> This thread is about a draft containing advice to operators on how to >> mitigate the problems caused by Anycast 6to4 (and Teredo). If you want >> to talk about expanding the scope of 6to4 beyond what is envisaged by >> the current standards, could you all kindly start a new thread? > > i want 6to4, teredo, 6rd, ... all dead dead dead. they are damaging > kludges to support pretend-v6 around lack of deployment. let the lack > of deployment show. the truth shall set you free. I think that's unfair on 6rd, which presents a genuine PA prefix to the IPv6 routing system. But yes, nobody wants 6to4 and Teredo to survive; that doesn't mean they will die before their time though. This draft is about reducing the pain until they die. Brian From jbates@brightok.net Mon Feb 7 13:09:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EFAF3A6F2A for ; Mon, 7 Feb 2011 13:09:15 -0800 (PST) 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.080, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CX84FU8r27DA for ; Mon, 7 Feb 2011 13:09:14 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id C5F423A6F1C for ; Mon, 7 Feb 2011 13:09:14 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17L9DdL024908; Mon, 7 Feb 2011 15:09:13 -0600 (CST) Message-ID: <4D505F79.907@brightok.net> Date: Mon, 07 Feb 2011 15:09:13 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian E Carpenter References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> In-Reply-To: <4D505345.8080006@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] Out of scope discussion [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:09:15 -0000 On 2/7/2011 2:17 PM, Brian E Carpenter wrote: > This thread is about a draft containing advice to operators on how to mitigate > the problems caused by Anycast 6to4 (and Teredo). If you want to talk about > expanding the scope of 6to4 beyond what is envisaged by the current > standards, could you all kindly start a new thread? Please? > > I won't be adding any proposals to expand the scope of 6to4 to my draft. Brian, Do you consider it out of scope to add the following? 1) If 6to4 Addressing is advertised via AAAA records, publishers should be aware that CGN/LSN/Provider NAT will break customers behind them from utilizing direct 6to4 communications 2) Implementers of CGN/LSN/Provider NAT (that doesn't have some really nifty 6to4 ALG) should block protocol 41 and return ICMP unreachables. (I presume this would be enough to close connections quickly and stop the 6to4 break delays) 3) Implementers of CGN/LSN/Provider NAT that support 6to4 anycast should implement NPTv6 to convert the 2002:: addresses inbound from IPv4 anycast to local IPv6 addresses. 4) All 6to4 anycast relays for 2002::/16 should make sure their IPv4 address is not behind NAT. I understand some of this is perhaps out of scope as you've defined, while some of it is still within scope (dealing directly with anycast). All of it I think addresses concerns of breakage. Jack From dr@cluenet.de Mon Feb 7 13:11:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9183A6F2A for ; Mon, 7 Feb 2011 13:11:20 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJrEHT6KJyB4 for ; Mon, 7 Feb 2011 13:11:17 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 640773A6F37 for ; Mon, 7 Feb 2011 13:11:15 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id A14051080D8; Mon, 7 Feb 2011 22:11:19 +0100 (CET) Date: Mon, 7 Feb 2011 22:11:19 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110207211119.GA13323@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <20110203224351.GA27225@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:11:20 -0000 On Thu, Feb 03, 2011 at 09:03:31PM -0600, Bernie Volz (volz) wrote: > Just as an FYI - there is no MTU "option" in DHCPv6 ... so, I'm not sure > what you're talking about when saying "we might advertise a higher MTU > in DHCPv6 replies" and "we might advertise a higher MTU in DHCPv6 > replies". Good point, thanks. I've let myself trick into thinking there is one, given that RFC2464 says in MTU context: > For purposes of this document, information received from DHCP is [...] So, RA MTU >1500 options are supposed to get ignored, DHCPv6 interface MTU option does not exist. How can we inform endpoints of MTU >1500 in an automated fashion? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From dr@cluenet.de Mon Feb 7 13:18:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33253A6EDE for ; Mon, 7 Feb 2011 13:18:22 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5VZM5XphYet for ; Mon, 7 Feb 2011 13:18:22 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 144EA3A6EBA for ; Mon, 7 Feb 2011 13:18:22 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id A68CF1080D8; Mon, 7 Feb 2011 22:18:26 +0100 (CET) Date: Mon, 7 Feb 2011 22:18:26 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110207211826.GB13323@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, Matt Crawford References: <20110203224351.GA27225@srv03.cluenet.de> <201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:18:23 -0000 On Fri, Feb 04, 2011 at 08:42:49AM -0500, Thomas Narten wrote: > The MTU option in an RA can be used to override the default, in cases > where the default value is somehow not optimal. Except that the IPoverEthernet RFC says to ignore MTU >1500 when received in RAs. So on Ethernet, RA MTU option may only decrease MTU, not increase compared to default. The reasoning behind that is beyond me. Looking at https://datatracker.ietf.org/doc/draft-ietf-ipngwg-trans-ethernet/history/, that paragraph was never substantially changed in the I-D process, just the paragraph referring to DHCP="manual" added. Matt, any chance of clarification? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From brian.e.carpenter@gmail.com Mon Feb 7 13:21:54 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955E23A6F37 for ; Mon, 7 Feb 2011 13:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPbEcxq0pQZF for ; Mon, 7 Feb 2011 13:21:53 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id AF0263A6F34 for ; Mon, 7 Feb 2011 13:21:52 -0800 (PST) Received: by fxm9 with SMTP id 9so5693426fxm.31 for ; Mon, 07 Feb 2011 13:21:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=omdQXvyEz7mESq7x/9a4ur8V2NCxCpFZXjHR3bAvsws=; b=NW4tyUw9pq+/1uh1n3+mwklg70SXroJoNxKmvLZftijpLpfWC9Gy3P5pZ6f1asniHl mO7xEvduK/GQwQ9cdSWH7zcefTIbA+ifa7VRMU/0CLBSfI4neRNqyOmNmoyWNWVKP+Bu nIZkSt9AMgv7/BVePKlFsfv4pdUPRltp56aMw= 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=xQjnUWfYZrlJJXdYS13nHu6Y06nxe7W79iAyBv9EgRVuw2GW+BKFURu90XkgNFQBi3 idGbf/e+Dt4Zq8ce9/grxi7cN64k30gmlgm19vyL3sv+IPjXjK2IILo9PAqqh3hRNrm/ CuU6EhfhBQbSWaGY1aK+ATjG8M70FR9xUtPo4= Received: by 10.223.83.134 with SMTP id f6mr12836087fal.1.1297113717196; Mon, 07 Feb 2011 13:21:57 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id j12sm1429386fax.33.2011.02.07.13.21.49 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 13:21:52 -0800 (PST) Message-ID: <4D50626A.8020801@gmail.com> Date: Tue, 08 Feb 2011 10:21:46 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> In-Reply-To: <20110207182807.GY44800@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:21:54 -0000 On 2011-02-08 07:28, Gert Doering wrote: > Hi, > > On Mon, Feb 07, 2011 at 04:17:48PM +0100, Ole Troan wrote: >> I just posted the following draft suggesting that we move the 6to4 documents to historic. > > I think 3056 is harmless enough as it is, provided connectivity to > "non-6to4" IPv6 is not happening (not *at all*, since you can't control > the return path even if the outgoig relay is sane). > > 3068 is where the breakage comes from. > > 3056 with "only used for packets going to 2002: addresses, sourced from > 2002: addresses" is useful. Yes, and this why (when someone first proposed solving this problem by telling people to STOP DOING THAT when they don't even know they're doing it) I started work on the draft-carpenter-v6ops-6to4-teredo-advisory draft. I strongly believe that's a much better use of IETF time and money than reclassifying RFC 3068 to Historic. And there is no reason to reclassify RFC 3056, because it isn't the one causing problems. So, this draft is (a) technically wrong, because it reclassifies RFC 3056, and the one that does harm is RFC 3068; (b) wrong process-wise (RFC 2026 section 4.2.4), because it hasn't been superseded and is in widespread use so cannot be called obsolete; (c) not constructive, because it doesn't offer solutions; (d) distracting us from useful work. Note that I am *not* trying to unnaturally prolong the life of 6to4 or Anycast 6to4. A good way to get rid of them is for all ISPs to deploy IPv6, for example. Brian From brian.e.carpenter@gmail.com Mon Feb 7 13:25:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912DB3A6F45 for ; Mon, 7 Feb 2011 13:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.442 X-Spam-Level: X-Spam-Status: No, score=-103.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8jB4KGJGD0B for ; Mon, 7 Feb 2011 13:25:47 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 7FC433A6F31 for ; Mon, 7 Feb 2011 13:25:47 -0800 (PST) Received: by bwz12 with SMTP id 12so5971216bwz.31 for ; Mon, 07 Feb 2011 13:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gNOrUzOnfNUYI7wMsWhT4xF30ThAUtbMOJHTAcSMK1A=; b=R3HPynIocm8GumoDZM+Kf3wdEA0LtrfvIpzOddPVH8syLuYmWQLm5nq3CJ8uzhvL0D eAxMeveh+z6e9lhjsp+nwPd+qp3KJ30vJmoL7P7cKnEVjJctbzifUWBU2eqe2NMDVEZq 36u0a38Zh4N2rffXbKnCXvzvmXVggbGFaPNQw= 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=v6WOSmONtkPBC2AqMTnS0onx1XmJrpo2Vwko7c3cBtbfsVDJPhPMOlJWv8MLgY78SR Bp2Ga7XJU6LBx5fbAAjEambOSBkIXWifk89ESecg1956jPTlhTWLSiMNNPfG/GKAEpau +qLwsqS27dq/8Z4iOdcoq+3hbcxEyN7/wpW4w= Received: by 10.204.72.199 with SMTP id n7mr9057836bkj.8.1297113951985; Mon, 07 Feb 2011 13:25:51 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id x38sm2331202bkj.1.2011.02.07.13.25.46 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 13:25:49 -0800 (PST) Message-ID: <4D506357.5060709@gmail.com> Date: Tue, 08 Feb 2011 10:25:43 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tore Anderson References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <8469C978-D60E-45AD-A534-A8E989DB8374@free.fr> <4D500BB0.70103@redpill-linpro.com> In-Reply-To: <4D500BB0.70103@redpill-linpro.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:25:48 -0000 On 2011-02-08 04:11, Tore Anderson wrote: > * R=C3=A9mi Despr=C3=A9s >=20 >> Thus, a server that advertises a native IPv6 address AND an 6to4 >> address becomes reachable by 6to4 clients even if they have no access >> to 6to4 relays. >> Reachability is thus increased, and I haven't found any adverse >> effect. >> Do you see any? >=20 > I actually attempted this a while back. It was a disaster and the > brokenness percentage skyrocketed. I don't think any content providers > in their right mind will publish AAAA-records for a 2002::/16 address. I will definitely add advice against that in the draft. Brian >=20 > Aben and Huston have both measured a 6to4 fail rate of around 15% - and= > that is with relays working fine in both directions! As long as nobody'= s > using 6to4 except as a last resort, it's not a problem, but the instant= > you publish 6to4 AAAAs, you will attract traffic from millions of hosts= > in networks that filter proto-41. >=20 > Regards, From drake@begriffli.ch Mon Feb 7 13:28:51 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804963A6F52 for ; Mon, 7 Feb 2011 13:28:51 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u726DWM-E-q1 for ; Mon, 7 Feb 2011 13:28:50 -0800 (PST) Received: from zwischenschaltung.begriffli.ch (zwischenschaltung.begriffli.ch [IPv6:2001:470:d:967::1]) by core3.amsl.com (Postfix) with ESMTP id 228BD3A6F5F for ; Mon, 7 Feb 2011 13:28:49 -0800 (PST) Received: from drache (drache [IPv6:fd73:dd44:9418:ffc9::2]) by zwischenschaltung.begriffli.ch (Postfix) with ESMTPS id 34645276B6 for ; Mon, 7 Feb 2011 14:28:53 -0700 (MST) Received: from drake by drache with local (Exim 4.72) (envelope-from ) id 1PmYdd-0006jj-1r for v6ops@ietf.org; Mon, 07 Feb 2011 14:28:49 -0700 Date: Mon, 7 Feb 2011 14:28:49 -0700 From: Drake Wilson To: v6ops@ietf.org Message-ID: <20110207212849.GA25796@drache.begriffli.ch> References: <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <1297091215.26424.13.camel@shakira.millnert.se> <1297093176.26424.28.camel@shakira.millnert.se> <4D505931.3010706@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D505931.3010706@gmail.com> X-Dragon-Conspiracy: There is no conspiracy. User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:28:51 -0000 Quoth Brian E Carpenter , on 2011-02-08 09:42:25 +1300: > Actually, I see his point. The probability in this scenario is that the v4 > path back to the client is actually better than the v6 path, but the problem is > that the client believes it's using IPv6, so it will be quite alarmed > if the SYN/ACK arrives back as an IPv4 packet. > > So it doesn't work, afaics, unless both ends contain this trick. Surely it can't work in the general case regardless? A 6to4 block could correspond to any number of otherwise-NAT44 hosts behind a single public IPv4 address, for instance. Essentially if this worked then we'd be in "v6 traffic can just be v4 traffic with some extra information" land. That wouldn't be terrible on all fronts, but I don't think we're anywhere close to it. So no, it doesn't make any sense to convert a 6to4 connection into an IPv4 connection. However, the other point is sound: with 6to4 clients it makes sense to be able to respond from a 6to4 address if your server also has native IPv4, because those packets will take the short path across IPv4 space rather than relying on relays between 6to4 space and other forms of IPv6 space, which appear to be the main reliability hitch with 6to4. > Brian ---> Drake Wilson From brian.e.carpenter@gmail.com Mon Feb 7 13:29:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490A83A6F64 for ; Mon, 7 Feb 2011 13:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.577 X-Spam-Level: X-Spam-Status: No, score=-103.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kgex1-QUdHs2 for ; Mon, 7 Feb 2011 13:28:59 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 48FD33A6F63 for ; Mon, 7 Feb 2011 13:28:59 -0800 (PST) Received: by fxm9 with SMTP id 9so5699737fxm.31 for ; Mon, 07 Feb 2011 13:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Powgvw56Dqc5IxRMhSBmxPdodX3HTgY7QzGqDZrpo9k=; b=CG+76mO4pub0n99laooJQVGpOrxzwP1L6xh8LXhJ2c+5/Xq90+GaywbkfpUow1oL0k TZdfKTlBbA676Fb7WZVFUbt9MI/LLYaCRB2kkn229MdA+mOrUo6LMZBcFlNX/X8dTS2Z zf1wsMJvefTAq+oJHt3eDM5sux76RyquMNvos= 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=uLMSnKPhswMbxsjhK7xSDSXx6l4gkTp1ZrCPuDWvkozRHQf9N31JeX+gWBrNgHpAW/ 2hcm0pmVqhmFZYxSh3bgEMD8ux/8E35btfV/InizrzcV3MMIZlKjAX6EDdPAyLB/wCPX +6+kzo33Op48NI2dL6/3FrqACNfqOw94GtPsM= Received: by 10.223.73.202 with SMTP id r10mr9829415faj.133.1297114143420; Mon, 07 Feb 2011 13:29:03 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id y3sm1435310fai.14.2011.02.07.13.28.59 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 13:29:02 -0800 (PST) Message-ID: <4D506418.9090706@gmail.com> Date: Tue, 08 Feb 2011 10:28:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jack Bates References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505F79.907@brightok.net> In-Reply-To: <4D505F79.907@brightok.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Keith Moore Subject: [v6ops] AAAA records [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:29:00 -0000 (I'm breaking Jack's message down into separate topics with appropriate subject headers) On 2011-02-08 10:09, Jack Bates wrote: ... > > 1) If 6to4 Addressing is advertised via AAAA records, publishers should > be aware that CGN/LSN/Provider NAT will break customers behind them from > utilizing direct 6to4 communications Yes, this is a good point. Should we simply recommend against advertising *any* 6to4 address in DNS, or at least provide a very strong health warning? Brian From brian.e.carpenter@gmail.com Mon Feb 7 13:31:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EAEE3A6F79 for ; Mon, 7 Feb 2011 13:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGWU62GLlBew for ; Mon, 7 Feb 2011 13:31:11 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 257313A6F78 for ; Mon, 7 Feb 2011 13:31:10 -0800 (PST) Received: by bwz12 with SMTP id 12so5976444bwz.31 for ; Mon, 07 Feb 2011 13:31:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LBrdepwgrHpZqc1DQR6aEC2XwRYfhBPeHP+25hMXVko=; b=lxM4yviKmGFLYM5Q7Gy0zoMJvejUQBZJZDTZt9i/wrAEtMcYdq4YTYLnpKNvDK/oka dAhnlZoGNIAEoyPGMzou+MQcUgsIHy++aWyQM/sBkj9TSGCiJDBPgeBNRPF+4oCQJ5fg REFLJjDQgB9ybfumdImyuM8kkFGvI5+LkZQe4= 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=Ykoe4aFw0tM6TxTUQDSZ/UfL3boOOjM1aNU/CR/79/qxsaxag7T1LcyV1dtFbdAErj 1rH7sL1+0kRdi75WKMJ/y6yRi+WquZVDw5DwzE1/PwVGDFdeW95u3EJXo8wJbx/L8xz0 JYZMGwYQmTw4lL7F7ZhVBZL5xXJRpmdMDKGRc= Received: by 10.204.113.75 with SMTP id z11mr702790bkp.90.1297114275632; Mon, 07 Feb 2011 13:31:15 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id b6sm2330671bkb.22.2011.02.07.13.31.11 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 13:31:14 -0800 (PST) Message-ID: <4D50649C.3050503@gmail.com> Date: Tue, 08 Feb 2011 10:31:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jack Bates References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505F79.907@brightok.net> In-Reply-To: <4D505F79.907@brightok.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Keith Moore Subject: [v6ops] CGN and proto 41 [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:31:12 -0000 On 2011-02-08 10:09, Jack Bates wrote: ... > 2) Implementers of CGN/LSN/Provider NAT (that doesn't have some really > nifty 6to4 ALG) should block protocol 41 and return ICMP unreachables. I think I already have that in, but I'll check. > > (I presume this would be enough to close connections quickly and stop > the 6to4 break delays) Not necessarily, depending on the client stack, but it certainly does no harm. Brian From jbates@brightok.net Mon Feb 7 13:37:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35AF83A6ABD for ; Mon, 7 Feb 2011 13:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMvuISuhmEah for ; Mon, 7 Feb 2011 13:37:19 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 274003A6DE0 for ; Mon, 7 Feb 2011 13:37:18 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17LbLUT002201; Mon, 7 Feb 2011 15:37:21 -0600 (CST) Message-ID: <4D506611.4030706@brightok.net> Date: Mon, 07 Feb 2011 15:37:21 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian E Carpenter References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505F79.907@brightok.net> <4D506418.9090706@gmail.com> In-Reply-To: <4D506418.9090706@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] AAAA records [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:37:20 -0000 On 2/7/2011 3:28 PM, Brian E Carpenter wrote: > > (I'm breaking Jack's message down into separate topics with > appropriate subject headers) > > > On 2011-02-08 10:09, Jack Bates wrote: > ... >> >> 1) If 6to4 Addressing is advertised via AAAA records, publishers should >> be aware that CGN/LSN/Provider NAT will break customers behind them from >> utilizing direct 6to4 communications > > Yes, this is a good point. Should we simply recommend against advertising > *any* 6to4 address in DNS, or at least provide a very strong health warning? > Based on Keith's argument, I would say a very strong health warning. It's not really our place to tell a publishing site that they can't break their own connectivity. Jack From brian.e.carpenter@gmail.com Mon Feb 7 13:39:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F10F53A6DE0 for ; Mon, 7 Feb 2011 13:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.582 X-Spam-Level: X-Spam-Status: No, score=-103.582 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFPn6MPcB9-u for ; Mon, 7 Feb 2011 13:39:49 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E020F3A6ABD for ; Mon, 7 Feb 2011 13:39:48 -0800 (PST) Received: by fxm9 with SMTP id 9so5709787fxm.31 for ; Mon, 07 Feb 2011 13:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=V2YcItFBKjFhP3k0/jgLwLUap98sh9bwbaPj71+P49I=; b=uTEJKVfGPXPO0lxYlMbsGaSTubkoXKWtUY/ReqwEWkPkdiO807req0tQ5jKxJO3LTA S+EdpISlxgXtsJKPTroHKEPmrnx3eNizXmNWCCbsvcAi9qcNESQvXy18cHTXbcMO4/VL VYEnh0lv7ra8fpGUBX7D9DJGqDxXOEweMaEsY= 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=b9yRPAWM7aX9PE8JgPTHD3R5q5ohVRcUTxUsB6a6j3lPyVh9Uctmsm+Ao2Oq7/0VON 2wmoNpuRBoyXt2lqVpIjtqciTemiLUHGtJCf9VQDaoZof4jCwBhHd29vtpJ51nj6sGLf GBbZx2paRNWVqSAlIhtkfte3/BAC7m46maaSQ= Received: by 10.223.101.129 with SMTP id c1mr15564726fao.25.1297114793478; Mon, 07 Feb 2011 13:39:53 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id r24sm1439637fax.27.2011.02.07.13.39.49 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 13:39:52 -0800 (PST) Message-ID: <4D5066A2.9020207@gmail.com> Date: Tue, 08 Feb 2011 10:39:46 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jack Bates References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505F79.907@brightok.net> In-Reply-To: <4D505F79.907@brightok.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Keith Moore Subject: [v6ops] NPTv6 [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:39:50 -0000 On 2011-02-08 10:09, Jack Bates wrote: ... > 3) Implementers of CGN/LSN/Provider NAT that support 6to4 anycast should > implement NPTv6 to convert the 2002:: addresses inbound from IPv4 > anycast to local IPv6 addresses. I think it's too soon to include that in operational advice; who knows whether NPT6 will even be published as an RFC? Also, this approach seems to me to be too complex to become accepted practice. Brian From brian.e.carpenter@gmail.com Mon Feb 7 13:41:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED8E33A6E3B for ; Mon, 7 Feb 2011 13:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.583 X-Spam-Level: X-Spam-Status: No, score=-103.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiK9XOV0uzyP for ; Mon, 7 Feb 2011 13:41:08 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 007173A6A0B for ; Mon, 7 Feb 2011 13:41:07 -0800 (PST) Received: by fxm9 with SMTP id 9so5711160fxm.31 for ; Mon, 07 Feb 2011 13:41:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=au3e997nKqQe8SjeeVv0l1FZnGNDmHCCcKjV5zQyISw=; b=LitAG2JFzlkzcrA2Lzl7XV0Sd+BwpZ7o4GUtQnUbnPhkt8j7KjWITa6v1TCF8CV0BN uKdS9NsXE/74lHbjwR6islJdEebu/n9ii/5FuRE+gvDkFpbYJW0b1s8akLwhs+cRiJoe CaxesdBPJc0a0wrxpJsylsz0D4qJyJ+1J/+oQ= 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=C3iy8TWk8UKyDVt3wWGxMbkAMI31xLmmpyJbJAIGIK9cKzFAMnF/QfXFsZNGIEa58V vSWV/i6xbc40/Wp1sY6N4/GIO+mng6ztJaBsGJzXMW2z4WQYdZwSFG2d1G+PXSlSCbAl 3ZZ3vIT/sLSY4Coa1n1+0nsgPQ8pj9htJ0ChM= Received: by 10.223.79.74 with SMTP id o10mr3917659fak.63.1297114872584; Mon, 07 Feb 2011 13:41:12 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 11sm1441196faw.20.2011.02.07.13.41.08 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 13:41:11 -0800 (PST) Message-ID: <4D5066F1.2000001@gmail.com> Date: Tue, 08 Feb 2011 10:41:05 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jack Bates References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505F79.907@brightok.net> In-Reply-To: <4D505F79.907@brightok.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Keith Moore Subject: [v6ops] Relays behind NAT [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:41:09 -0000 On 2011-02-08 10:09, Jack Bates wrote: ... > 4) All 6to4 anycast relays for 2002::/16 should make sure their IPv4 > address is not behind NAT. That was far too obvious for me to mention ;-) Thanks Brian From jbates@brightok.net Mon Feb 7 13:42:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C973A6E87 for ; Mon, 7 Feb 2011 13:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.193 X-Spam-Level: X-Spam-Status: No, score=-3.193 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2wVvA9Qzh3r for ; Mon, 7 Feb 2011 13:42:34 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id CC3073A6ABD for ; Mon, 7 Feb 2011 13:42:33 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p17LgZkr004273; Mon, 7 Feb 2011 15:42:35 -0600 (CST) Message-ID: <4D50674B.8000402@brightok.net> Date: Mon, 07 Feb 2011 15:42:35 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cameron Byrne References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:42:34 -0000 On 2/7/2011 1:44 PM, Cameron Byrne wrote: > Nope, and not interested since customers don't care about this 6to4 > service. The only people that care are network admins that have to > deal when it breaks the user or the network. Customers care that > facebook and google and pandora work ... they are generally not > interested in these transport messes, and that is why IPv6 is still > not deployed in MOST place. Ahh, if you have real IPv6 connectivity, then I agree that supporting 6to4 is unwarranted in any form. The only place I consider it a concern is for isolated areas of ISP networks that must use CGN but cannot offer IPv6 native (or other better migration mechanisms). Jack From iesg-secretary@ietf.org Mon Feb 7 13:45:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1928B3A6F81; Mon, 7 Feb 2011 13:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmxkM4P1TafU; Mon, 7 Feb 2011 13:45:18 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042923A6FB0; Mon, 7 Feb 2011 13:45:18 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110207214518.31350.8955.idtracker@localhost> Date: Mon, 07 Feb 2011 13:45:18 -0800 Cc: v6ops mailing list , Internet Architecture Board , v6ops chair , RFC Editor Subject: [v6ops] Document Action: 'Security Concerns With IP Tunneling' to Informational RFC (draft-ietf-v6ops-tunnel-security-concerns-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:45:22 -0000 The IESG has approved the following document: - 'Security Concerns With IP Tunneling' (draft-ietf-v6ops-tunnel-security-concerns-04.txt) as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-tunnel-security-concerns/ Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' RFC Editor Note * In the Abstract OLD: The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed today. NEW: The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. * After Section 5.1.1. OLD: NEW: 5.1.2. Discussion Several tunnel protocols use endpoint addresses that can be algorithmically derived from some known values. These addresses are structured and the fields contained in them can be fairly predictable. This reduces the search space for an attacker and reduces the resistance of the address to scanning attacks. e.g. Teredo addresses are formed using a well known prefix, client and server IPv4 addresses, the client port and a few flags. With a fairly narrow search space for most of these fields, it is easy to guess the tunnel endpoint address. 5.1.3. Recommendations It is recommended that the tunnel protocol developers use tunnel endpoint addresses that are not easily guessable. When the tunnel endpoint addresses are structured and fairly guessable, it is recommended that the implementation use any unused fields in the address to provide additional entropy to the address in order to reduce the address-scanning risks. e.g. This could be done by setting these unused fields to some random values. * In Section 6.1.3 OLD: The scope of the attack can also be reduced by limiting tunneling use in general but especially in preferring native IPv4 to tunneled IPv6; this is because it is reasonable to expect that banks and similar web sites will continue to be accessible over IPv4 for as long as a significant fraction of their customers are still IPv4-only. NEW: The scope of the attack can also be reduced by limiting tunneling use in general but especially in preferring native IPv4 to tunneled IPv6 while connecting to peers who are accessible over IPv4, as doing so precludes attacks that are facilitated by changing the tunnel server setting. From crawdad@fnal.gov Mon Feb 7 13:53:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298283A6E19 for ; Mon, 7 Feb 2011 13:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4B2bD5U+HZP for ; Mon, 7 Feb 2011 13:53:26 -0800 (PST) Received: from mailgw1.fnal.gov (mailgw1.fnal.gov [131.225.111.11]) by core3.amsl.com (Postfix) with ESMTP id ABDC03A6E13 for ; Mon, 7 Feb 2011 13:53:25 -0800 (PST) Received: from mailav2.fnal.gov (mailav2.fnal.gov [131.225.111.20]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with SMTP id <0LG900JFYOQGJD@mailgw1.fnal.gov> for v6ops@ietf.org; Mon, 07 Feb 2011 15:53:07 -0600 (CST) Received: from mailgw1.fnal.gov ([131.225.111.11]) by mailav2.fnal.gov (SAVSMTP 3.1.7.47) with SMTP id M2011020715532923719 for ; Mon, 07 Feb 2011 15:53:29 -0600 Received: from conversion-daemon.mailgw1.fnal.gov by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) id <0LG900C01OEQXD@mailgw1.fnal.gov> (original mail from crawdad@fnal.gov) for v6ops@ietf.org; Mon, 07 Feb 2011 15:53:07 -0600 (CST) Received: from dhcp-131-225-82-71.dhcp.fnal.gov (dhcp-131-225-82-71.dhcp.fnal.gov [131.225.82.71]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with ESMTPSA id <0LG900JRVOSJ0T@mailgw1.fnal.gov>; Mon, 07 Feb 2011 15:53:07 -0600 (CST) Date: Mon, 07 Feb 2011 15:53:29 -0600 From: Matt Crawford In-reply-to: <20110207211826.GB13323@srv03.cluenet.de> To: Daniel Roesen Message-id: <4ABF4068-018A-4D24-93A7-B1069AC99333@fnal.gov> MIME-version: 1.0 X-Mailer: Apple Mail (2.1082) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <20110203224351.GA27225@srv03.cluenet.de> <201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com> <20110207211826.GB13323@srv03.cluenet.de> X-Mailman-Approved-At: Mon, 07 Feb 2011 14:00:30 -0800 Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:53:32 -0000 (If this gets bounced from v6ops for my non-membership in the list, please repost.) On Feb 7, 2011, at 3:18 PM, Daniel Roesen wrote: > On Fri, Feb 04, 2011 at 08:42:49AM -0500, Thomas Narten wrote: >> The MTU option in an RA can be used to override the default, in cases >> where the default value is somehow not optimal. > > Except that the IPoverEthernet RFC says to ignore MTU >1500 when received > in RAs. So on Ethernet, RA MTU option may only decrease MTU, not increase > compared to default. > > The reasoning behind that is beyond me. > > Looking at > https://datatracker.ietf.org/doc/draft-ietf-ipngwg-trans-ethernet/history/, > that paragraph was never substantially changed in the I-D process, just > the paragraph referring to DHCP="manual" added. > > Matt, any chance of clarification? The text was nearly the same in RFC 1972. I have the nroff source of all drafts of both the i-d's, but I don't have all my email from 15 years ago so I cannot say who raised and/or endorsed this point. Reaching back almost six years, there was a relevant discussion on this question. I think the same text answers here ... Begin forwarded message: > From: Hugh LaMaster > Date: July 20, 2005 7:15:52 PM CDT > To: Matt Crawford > Subject: IPv6 and Jumbo Frames on Ethernet > Reply-To: Hugh LaMaster > > Hi, > > There is an ongoing discussion on the "ipv6@ietf.org" > mailing list wrt jumbo frames. Is it your opinion that > RFC2464 prohibits (that is, if something is supposed > to be strictly in compliance with RFC2464) the IPv6 > MTU from being greater than 1500 Bytes? That is one > interpretation. I don't read it that way myself, but, > apparently whoever implemented the FreeBSD IPv6 code > interprets it that way also-- that the RFC prohibits > IPv6 MTU > 1500. > > Regards, > Hugh LaMaster > NASA ARC/NAS/NREN > Begin forwarded message: > From: Matt Crawford > Date: July 20, 2005 8:52:48 PM CDT > To: Hugh LaMaster > Subject: Re: IPv6 and Jumbo Frames on Ethernet > >> There is an ongoing discussion on the "ipv6@ietf.org" >> mailing list wrt jumbo frames. Is it your opinion that >> RFC2464 prohibits (that is, if something is supposed >> to be strictly in compliance with RFC2464) the IPv6 >> MTU from being greater than 1500 Bytes? That is one >> interpretation. I don't read it that way myself, but, >> apparently whoever implemented the FreeBSD IPv6 code >> interprets it that way also-- that the RFC prohibits >> IPv6 MTU > 1500. > > Hm. It is only supposed to mean that Router Advertisements cannot increase the MTU above whatever it was otherwise believed to be, and that in the absence of configuration information (including DHCP), it is presumed to be 1500. > > I'd have to agree that it could have been a bit clearer. > > Matt Crawford > FNAL/CD/CCF/Wide Area Systems > +1 630 840 3461 > Begin forwarded message: > From: Hugh LaMaster > Date: July 21, 2005 1:15:45 PM CDT > To: Matt Crawford > Subject: Re: IPv6 and Jumbo Frames on Ethernet > Reply-To: Hugh LaMaster > > Matt Crawford wrote: > >> Hm. It is only supposed to mean that Router Advertisements cannot >> increase the MTU above whatever it was otherwise believed to be, and >> that in the absence of configuration information (including DHCP), it is >> presumed to be 1500. > > Do you mind if I repost this statement to the mailing list? > > Regards, > Hugh LaMaster > Begin forwarded message: > From: Matt Crawford > Date: July 21, 2005 2:04:05 PM CDT > To: Hugh LaMaster > Subject: Re: IPv6 and Jumbo Frames on Ethernet > > > On Jul 21, 2005, at 13:15, Hugh LaMaster wrote: > >>> Hm. It is only supposed to mean that Router Advertisements cannot >>> increase the MTU above whatever it was otherwise believed to be, and >>> that in the absence of configuration information (including DHCP), it is >>> presumed to be 1500. >> >> Do you mind if I repost this statement to the mailing list? > > No. Please include the admission that perhaps it could have been clearer. Remember the old "We'll fix it in Draft" mantra that used to be the ipngwg refrain? > > Matt > From Wesley.E.George@sprint.com Mon Feb 7 14:32:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476C03A6FAE for ; Mon, 7 Feb 2011 14:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxXTC0pR+CP5 for ; Mon, 7 Feb 2011 14:31:59 -0800 (PST) Received: from DB3EHSOBE006.bigfish.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by core3.amsl.com (Postfix) with ESMTP id 2BBD93A6F31 for ; Mon, 7 Feb 2011 14:31:57 -0800 (PST) Received: from mail35-db3-R.bigfish.com (10.3.81.250) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.8; Mon, 7 Feb 2011 22:32:01 +0000 Received: from mail35-db3 (localhost.localdomain [127.0.0.1]) by mail35-db3-R.bigfish.com (Postfix) with ESMTP id 5977264039A; Mon, 7 Feb 2011 22:32:01 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zf7Izbb2cK542N9371Pzz1202hzz8275dh1033ILz2fh2a8h668h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI Received: from mail35-db3 (localhost.localdomain [127.0.0.1]) by mail35-db3 (MessageSwitch) id 129711792163944_26700; Mon, 7 Feb 2011 22:32:01 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.243]) by mail35-db3.bigfish.com (Postfix) with ESMTP id 0435EB3804F; Mon, 7 Feb 2011 22:32:01 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 7 Feb 2011 22:32:00 +0000 Received: from PLSWEH03.ad.sprint.com (PLSWEH03.corp.sprint.com [144.226.242.132]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p17MVfkw021077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Feb 2011 16:31:58 -0600 Received: from PDAWM12B.ad.sprint.com ([fe80::64c8:fd69:1029:79b0]) by PLSWEH03.ad.sprint.com ([fe80::a470:17cb:6a7f:3a52%15]) with mapi id 14.01.0270.001; Mon, 7 Feb 2011 16:31:41 -0600 From: "George, Wes E [NTK]" To: Brian E Carpenter , Gert Doering Thread-Topic: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 Thread-Index: AQHLxw0XLh0PbB1uTU6nFEoF+yqYQZP2m6Xg Date: Mon, 7 Feb 2011 22:31:40 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E3665A8@PDAWM12B.ad.sprint.com> References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> In-Reply-To: <4D50626A.8020801@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.28] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0109_01CBC6EC.E5CE11A0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 22:32:00 -0000 ------=_NextPart_000_0109_01CBC6EC.E5CE11A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Monday, February 07, 2011 4:22 PM To: Gert Doering Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 >Yes, and this why (when someone first proposed solving this problem by telling people to STOP DOING THAT when they don't even >know they're doing it) I started work on the draft-carpenter-v6ops-6to4-teredo-advisory >draft. I strongly believe that's a much better use of IETF time and money than reclassifying RFC 3068 to Historic. And there is no >reason to reclassify RFC 3056, because it isn't the one causing problems. >So, this draft is >a) technically wrong, because it reclassifies RFC 3056, and the one that does harm is RFC 3068; >(b) wrong process-wise (RFC 2026 section 4.2.4), because it hasn't been superseded and is in widespread use so cannot be called obsolete; >(c) not constructive, because it doesn't offer solutions; >(d) distracting us from useful work. [WEG] +1 Before we call 6to4 dead, I'd like to see results from things like World IPv6 day to see how things actually worked without all of the whitelists and URL hacks in the way, especially if some providers begin taking the recommendations in draft-Carpenter seriously to improve 6to4's performance over the coming months. I note that several larger providers have deployed 6to4 relays because they realize that the traffic exists whether they like it or not, and they'd rather it work more reliably for their customers. There are lots of people fond of saying "just abandon 6to4; it doesn't work" when most of the reasons it doesn't work are manageable given some proper recommendations. We need to think very carefully about making recommendations to abandon protocols that are still in use. We want people to deploy IPv6, but we seem content to ignore valid transition techniques *that are already deployed* as "not really IPv6" not because they are technically flawed, but because we didn't provide enough guidance to implement them in a way that makes them consistently functional. And then we wonder why people look at the IETF as confused, inconsistent, disconnected from reality, etc. Does it make sense for new devices to support 6to4 as their *only* IPv6 support? Absolutely not! But like IPv4, we're stuck with what's already out there, and as an operator, I'd rather make it work properly than ignore it, because I can't control when it goes away. And if it makes a few more devices IPv6-capable before dual-stack is there, that's a win in my mind. Wes George ------=_NextPart_000_0109_01CBC6EC.E5CE11A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDITCCAx0CAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB8DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAyMDcyMjMxNDhaMCMGCSqGSIb3DQEJBDEWBBTSexeESqsp y6AWwNRNj85du5IbzzBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjCBlwYJKwYB BAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJp bnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNl IElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJEAILMYGJoIGGMHgx EzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/Is ZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRo b3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYBDf4J2n5F/Kbh7tFf9qvbJdHP7lBM6 zxh7Y2H3ggfUqjQ7OtT+RwLnty/bYzfUo3jW6epXhF5xR7/hE/ytS84gjEXOur4QymIvSbGS/wrS wA2mXw05BfCJuLoKnBj5f2RUP79cq45EuwqFEgsZ80TTEuoXe+LWEqVmebANWb/1gwAAAAAAAA== ------=_NextPart_000_0109_01CBC6EC.E5CE11A0-- From moore@network-heretics.com Mon Feb 7 14:44:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461E13A6F81 for ; Mon, 7 Feb 2011 14:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPB3w9ueVn77 for ; Mon, 7 Feb 2011 14:44:33 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id F01693A6EFE for ; Mon, 7 Feb 2011 14:44:32 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmZoy-0006sn-Dq; Mon, 07 Feb 2011 17:44:37 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-32-983893298 From: Keith Moore In-Reply-To: <4D505931.3010706@gmail.com> Date: Mon, 7 Feb 2011 17:44:33 -0500 Message-Id: <1B4A840D-0D31-4D2D-86F9-D0D08D77FF11@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <1297091215.26424.13.camel@shakira.millnert.se> <1297093176.26424.28.camel@shakira.millnert.se> < 4D505931.3010706@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940c1175659e7ba69efcb8e1d020a445998350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 22:44:34 -0000 --Apple-Mail-32-983893298 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 7, 2011, at 3:42 PM, Brian E Carpenter wrote: >>>>=20 >>> Sorry Keith, I'll try again. >>>=20 >>> First, I was just agreeing that a content server should not send = packets >>> towards 6to4 anycast space. >>>=20 >>> Then, I tried to explain a possible implementation method for a >>> dual-stacked content server: >>>=20 >>> 1) A content server has native IPv6 and IPv4, eg is dual-stacked. >>> 2) A TCP SYN arrives on its IPv6 interface from 2002::/16 space. >>> 3) Return packets are sent as IPv6-over-IPv4 to the unicast address >>> (Brian did note some brokenness here; perhaps it can be helped by = using >>> source address 192.88.99.1?) >>> 4) When the connection is delivered to the application layer, it is >>> converted into a IPv4 connection, by decoding the IPv4 address that = is >>> encoded in 2002::/16 as the source address. >>> 5) =46rom now on, it's just IPv4 for the applications which they = should >>> be fairly familiar with. >>>=20 >>> Did this make more sense? >>=20 >> no. it makes no sense at all to convert a 6to4 connection into an = ipv4 connection. >=20 > Actually, I see his point. The probability in this scenario is that = the v4 > path back to the client is actually better than the v6 path, but the = problem is > that the client believes it's using IPv6, so it will be quite alarmed > if the SYN/ACK arrives back as an IPv4 packet. >=20 > So it doesn't work, afaics, unless both ends contain this trick. Correct. And more generally, the client _application_ chose to open a = connection to a v6 address and has every right to expect that it is = using v6 and not v4. There are a great many subtle differences between = the two, and sometimes applications need to know about them. Keith --Apple-Mail-32-983893298 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Sorry Keith, I'll try = again.

First, I was just agreeing that = a content server should not send = packets
towards 6to4 anycast = space.

Then, I tried to explain a = possible implementation method for = a
dual-stacked content = server:

1) A content server has native = IPv6 and IPv4, eg is = dual-stacked.
2) A TCP SYN arrives on its IPv6 = interface from 2002::/16 space.
3) Return packets are sent as = IPv6-over-IPv4 to the unicast = address
(Brian did note some brokenness here; perhaps it can be = helped by using
source address = 192.88.99.1?)
4) When the connection is = delivered to the application layer, it = is
converted into a IPv4 connection, by decoding the IPv4 = address that is
encoded in 2002::/16 as the = source address.
5) =46rom now on, it's just IPv4 = for the applications which they = should
be fairly familiar = with.

Did this make more = sense?

no.  it = makes no sense at all to convert a 6to4 connection into an ipv4 = connection.

Actually, I see his point. The = probability in this scenario is that the v4
path back to the client = is actually better than the v6 path, but the problem is
that the = client believes it's using IPv6, so it will be quite alarmed
if the = SYN/ACK arrives back as an IPv4 packet.

So it doesn't work, = afaics, unless both ends contain this = trick.

Correct.  And more = generally, the client _application_ chose to open a connection to a v6 = address and has every right to expect that it is using v6 and not v4. =  There are a great many subtle differences between the two, and = sometimes applications need to know about = them.

Keith

= --Apple-Mail-32-983893298-- From Fred.L.Templin@boeing.com Mon Feb 7 14:46:32 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC913A6F81 for ; Mon, 7 Feb 2011 14:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, GB_AFFORDABLE=1, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdDiODcKzQdY for ; Mon, 7 Feb 2011 14:46:31 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 19A4A3A6E5B for ; Mon, 7 Feb 2011 14:46:31 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p17MkVBb011700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Feb 2011 14:46:31 -0800 (PST) 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 p17MkVQB023913; Mon, 7 Feb 2011 14:46:31 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p17MkUhf023896 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 7 Feb 2011 14:46:31 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Mon, 7 Feb 2011 14:46:30 -0800 From: "Templin, Fred L" To: Fred Baker Date: Mon, 7 Feb 2011 14:46:29 -0800 Thread-Topic: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 Thread-Index: AcvG+vyF6/NqKpXhS+eOwoAG2mX7hAAE8uUA Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> In-Reply-To: <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 22:46:32 -0000 Hi Fred,=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Monday, February 07, 2011 11:12 AM > To: Templin, Fred L > Cc: IPv6 Operations > Subject: Re: [v6ops] Fwd: New Version Notificationfor=20 > draft-troan-v6ops-6to4-to-historic-00 >=20 >=20 > On Feb 7, 2011, at 10:04 AM, Templin, Fred L wrote: > > Why not something better? Why not IRON: >=20 > "Better" is a value judgement, a comparison of a proposed=20 > solution with a set of requirements, and is often somewhat in=20 > the eye of the beholder. My (partial) set of requirements that IRON satisfies includes: 1) IPv6 rollout - must support fast incremental deployment of IPv6 as IPv4 address depletion escalates 2) NAT traversal - must work through NATs w/o being unduly dependent on NAT state stability =20 3) Routing Scaling - scaling to large numbers of end systems and networks using IPv6 must not adversely impact routing scaling in the core 4) Mobility management - must maintain generally shortest path routing for mobile end systems and networks without producing undue routing churn in the core 5) Multihoming - must support simultaneous connections through multiple providers 6) Traffic engineering - must allow customer to dynamically manage both in-bound and out-bound traffic classification, i.e., even if the link paths are asymmetric in the forward and reverse directions. (For example, send packets out via a 3G link and receive packets back via a DOCSIS link.)=20 7) Provider (In)dependence - end systems and networks should be able to use a single, stable IPv6 address or prefix via multiple provider connections. > I think it would be fair to say that the objective of v6ops=20 > is to deploy, operate, and maintain a ubiquitous IPv6 network=20 > comparable to the IPv4 network of today and independent of=20 > any underlying infrastructure. There may well be underlying=20 > infrastructure of various kinds - ATM, MPLS, various WAN=20 > technologies, or "Ethernet" in whatever form it may appear at=20 > the moment. However, the networks that the operators on this=20 > list operate are not networks in which one expects hosts to=20 > dynamically place circuits on an infrastructure of a=20 > different kind to provide service, but to operate as a=20 > ubiquitous and stable service.=20 >=20 > It may be fair to ask each type of technology to describe its=20 > relationship to that kind of service, and to carefully=20 > consider the operational implications of running it. That's=20 > where Ole is coming from in suggesting that RFC 3056 be=20 > retired; it depends on an underlying infrastructure (IPv4=20 > addressing and anycast servers), and has been a source of=20 > problems for ISPs trying to deploy native IPv6 service as=20 > noted in RFCs 3964 and 4472, and in the drafts=20 > draft-ietf-v6ops-tunnel-loops,=20 > draft-ietf-v6ops-tunnel-security-concerns,=20 > draft-kuarsingh-v6ops-6to4-provider-managed-tunnel, and=20 > draft-vandevelde-v6ops-harmful-tunnels. That is also at least=20 > in part where questions of other overlay networks like Teredo come in. The class of services you are referring to above have in common that they embed an IPv4 address within the IPv6 address and later extract such IPv4 addresses for stateless tunnel endpoint discovery. IRON does not share this property. =20 > If I can summarize Keith's concern with 6rd, it is not that=20 > it doesn't deploy an IPv6-capable service; it is that the=20 > service has a smaller Path MTU than the native MTU of links=20 > he uses, often has a broken PMTU implementation due to ICMPv6=20 > filtering, and is not native. If I can summarize the views of=20 > those using it (such as a Dutch provider I spoke with=20 > Wednesday in London), it's not that they don't want or expect=20 > to deploy a native IPv6 service, it's that they want to=20 > deploy an IPv6 service now and have infrastructure that they=20 > can't immediately upgrade (such as, in the Dutch case I=20 > mentioned, a service network that they have to use that is=20 > IPv4-only for the foreseeable future). >=20 > Similar exchanges can be described around dIVI, 4rd, and=20 > ds-lite. Fundamentally, if my bread and butter today is IPv4=20 > and my shiny new IPv6 network will in the nature of the case=20 > require some time to harden, why would I disrupt my bread and=20 > butter to deploy the new, and while doing so make my present=20 > business model dependent on the not-yet-hardened network?=20 > They are very reasonable ways to remove IPv4 from a dual=20 > stack network, but from the perspective of risk an odd way to=20 > deploy the IPv6 network. >=20 > If you want to make the case that IRON is "better" than=20 > something else, I think the thing to do is write the=20 > applicability statement. We already have one of these in the RFC editor queue: http://www.rfc-editor.org/internet-drafts/draft-russert-rangers-05.txt Section 6 of that document in particular provides a problem statement for which IRON is the proposed solution. > The networks on this list operate as=20 > a ubiquitous and stable service comparable to the present=20 > IPv4 network and independent of any underlying=20 > infrastructure; anything else needs to help them move toward=20 > that goal, and needs by nature to be effortlessly removed=20 > from the network as native IPv6 deployment settles in. What=20 > is the applicability of IRON to such a network? I don't agree with the "needs to be effortlessly removed" comment - even if and when a native IPv6 deployment settles in - since IRON runs just fine over either IPv4 or IPv6 networks. Although IRON does offer a fast-path incremental deployment of a tunneled IPv6 service for the near term, that service will still be attractive to customers for the long term due to its support for mobility, multihoming, traffic engineering and provider (in)dependence. The reason I write it as "provider (in)dependence" is that IRON requires someone to stand up an affordable service; see: http://tools.ietf.org/html/draft-templin-iron-pm To prospective IRON network operators, what is required is strategic deployment of a few IRON relays (maybe O(10) of these) and a number of IRON servers (maybe O(100) to O(1000) of these). The IRON relays are full-fledged routers that run eBGP externally and iBGP internally. The IRON servers are low-cost commodity devices that can be purchased at your local computer wholesaler. Performance can therefore be tuned by ensuring that the IRON relays are well-deployed (much in the same way as for responsibly-deployed 6rd/6to4 relays) and/or by adding additional low-cost servers in regions where server load may become substantial. Again, IRON is about fast transition today with a service customers will find attractive continuing into the long term - a once-and-done alternative. Thanks - Fred fred.l.templin@boeing.com= From randy@psg.com Mon Feb 7 14:57:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6CF33A6EA8 for ; Mon, 7 Feb 2011 14:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVsta6fGT68p for ; Mon, 7 Feb 2011 14:57:39 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id A496C3A6E5B for ; Mon, 7 Feb 2011 14:57:38 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pma1e-000K0w-A0; Mon, 07 Feb 2011 22:57:42 +0000 Date: Mon, 07 Feb 2011 14:57:42 -0800 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <4D505E87.8020706@gmail.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505E87.8020706@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] Out of scope discussion [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 22:57:39 -0000 >> i want 6to4, teredo, 6rd, ... all dead dead dead. they are damaging >> kludges to support pretend-v6 around lack of deployment. let the >> lack of deployment show. the truth shall set you free. > I think that's unfair on 6rd, which presents a genuine PA prefix to > the IPv6 routing system. 6rd is just one more in a long line of hacks to allow somone running windows at home to pretend that their provider is giving them ipv6 transport when, in fact, they do not. randy From Fred.L.Templin@boeing.com Mon Feb 7 15:20:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF99B3A6FD5 for ; Mon, 7 Feb 2011 15:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.041 X-Spam-Level: X-Spam-Status: No, score=-6.041 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40X+FYto0-vb for ; Mon, 7 Feb 2011 15:20:06 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id A6C9F3A6FB6 for ; Mon, 7 Feb 2011 15:20:05 -0800 (PST) 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 p17NK7eo017632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Feb 2011 17:20:07 -0600 (CST) 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 p17NK6gB018075; Mon, 7 Feb 2011 17:20:06 -0600 (CST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p17NK3oU018002 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 7 Feb 2011 17:20:04 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Mon, 7 Feb 2011 15:20:02 -0800 From: "Templin, Fred L" To: Randy Bush , Brian E Carpenter Date: Mon, 7 Feb 2011 15:20:01 -0800 Thread-Topic: [v6ops] Out of scope discussion [Fwd:I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] Thread-Index: AcvHGnLJ5XJyQRffRki5gWq8Mk2e6QAAUZPw Message-ID: References: <4D4A2401.2020500@gmail.com><7474B6BC-EC21-447A-B2F4-1CB666E0ABA 1@employees.org><92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl><4D4ACEFA .3080106@brightok.net><7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl><6F C549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net><4905BDD3-DE25-4CE9-854D-7673705DF74E@free.f r><4D4C3E51.8070503@brightok.net><3E3F1DEC-161F-42E1-9210-907F23F43A12@gmai l.com><4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net><4D4C837F.8020306@gmail.com><4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505E87.8020706@gmail.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: IPv6 Operations Subject: Re: [v6ops] Out of scope discussion [Fwd:I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:20:08 -0000 =20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Randy Bush > Sent: Monday, February 07, 2011 2:58 PM > To: Brian E Carpenter > Cc: IPv6 Operations > Subject: Re: [v6ops] Out of scope discussion [Fwd:I-D=20 > Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] >=20 > >> i want 6to4, teredo, 6rd, ... all dead dead dead. they=20 > are damaging > >> kludges to support pretend-v6 around lack of deployment. let the > >> lack of deployment show. the truth shall set you free. > > I think that's unfair on 6rd, which presents a genuine PA prefix to > > the IPv6 routing system. >=20 > 6rd is just one more in a long line of hacks to allow somone running > windows at home to pretend that their provider is giving them ipv6 > transport when, in fact, they do not. Then, long live IRON! Fred =20 > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From jbates@brightok.net Mon Feb 7 15:26:37 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C308B3A6FAE for ; Mon, 7 Feb 2011 15:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.196 X-Spam-Level: X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nItcc8IbF507 for ; Mon, 7 Feb 2011 15:26:37 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 010293A6E05 for ; Mon, 7 Feb 2011 15:26:36 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p17NQcnp001011; Mon, 7 Feb 2011 17:26:38 -0600 (CST) Message-ID: <4D507FAF.3060503@brightok.net> Date: Mon, 07 Feb 2011 17:26:39 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Victor Kuarsingh References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Roesen , v6ops@ietf.org, Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:26:37 -0000 On 2/7/2011 2:39 PM, Victor Kuarsingh wrote: > Jack, > > There is code we are now testing which implements 6to4 with NAT66. This > will translate 2002::/16 to provider block. (Based > draft-kuarsingh-v6ops-6to4-provider-managed-tunnel) > Thanks. I believe this is a great benefit to 6to4 anycast in regards to CGN networks that must still support 6to4. I theoretically would solve the no return path problem, but I'm worried about the NAT66 in a general case. Jack From jbates@brightok.net Mon Feb 7 15:32:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A03B3A6E7A for ; Mon, 7 Feb 2011 15:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zs0M4mpwxAlG for ; Mon, 7 Feb 2011 15:32:43 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id BB1E63A6E05 for ; Mon, 7 Feb 2011 15:32:43 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p17NWk6L003139; Mon, 7 Feb 2011 17:32:46 -0600 (CST) Message-ID: <4D50811E.7080905@brightok.net> Date: Mon, 07 Feb 2011 17:32:46 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian E Carpenter References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505F79.907@brightok.net> <4D5066A2.9020207@gmail.com> In-Reply-To: <4D5066A2.9020207@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] NPTv6 [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:32:44 -0000 On 2/7/2011 3:39 PM, Brian E Carpenter wrote: > On 2011-02-08 10:09, Jack Bates wrote: > ... >> 3) Implementers of CGN/LSN/Provider NAT that support 6to4 anycast should >> implement NPTv6 to convert the 2002:: addresses inbound from IPv4 >> anycast to local IPv6 addresses. > > I think it's too soon to include that in operational advice; who knows > whether NPT6 will even be published as an RFC? > > Also, this approach seems to me to be too complex to become accepted > practice. I don't really like it, but it's the only way I've seen to support 6to4 anycast behind CGN. The fallback is to disallow 6to4. I think it is good to point out an option, even if we believe it is better to not use 6to4 in such environments. There are many who won't even think of it. Jack From moore@network-heretics.com Mon Feb 7 15:46:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80A583A6FDB for ; Mon, 7 Feb 2011 15:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9fVLZ1IXO3N for ; Mon, 7 Feb 2011 15:46:47 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 23B313A6FD9 for ; Mon, 7 Feb 2011 15:46:47 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmanA-0000XC-RZ; Mon, 07 Feb 2011 18:46:50 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-33-987619093 From: Keith Moore In-Reply-To: <4D50811E.7080905@brightok.net> Date: Mon, 7 Feb 2011 18:46:38 -0500 Message-Id: <1CD9F144-5AF6-4601-B558-F06CF4716830@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505F79.907@brightok.net> <4D5066A2.9020207@gmail.com> <4D50811E.7080905@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940b381ea84792f372367d54fb3489a5c6f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] NPTv6 [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:46:48 -0000 --Apple-Mail-33-987619093 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 7, 2011, at 6:32 PM, Jack Bates wrote: > On 2/7/2011 3:39 PM, Brian E Carpenter wrote: >> On 2011-02-08 10:09, Jack Bates wrote: >> ... >>> 3) Implementers of CGN/LSN/Provider NAT that support 6to4 anycast = should >>> implement NPTv6 to convert the 2002:: addresses inbound from IPv4 >>> anycast to local IPv6 addresses. >>=20 >> I think it's too soon to include that in operational advice; who = knows >> whether NPT6 will even be published as an RFC? >>=20 >> Also, this approach seems to me to be too complex to become accepted >> practice. >=20 > I don't really like it, but it's the only way I've seen to support = 6to4 anycast behind CGN. The fallback is to disallow 6to4. I think it is = good to point out an option, even if we believe it is better to not use = 6to4 in such environments. There are many who won't even think of it. To me this seems like it's of such limited applicability that it will = never see actual use. The correct fallback, of course, is for ISPs using CGN to: - provide an option for their customers who need it to get a native v4 = address via some other means (say by tunneling), and permit 6to4 over = that, and/or - provide native v6 for all of their customers using CGN, and encourage = their customers to migrate to v6 if CGN doesn't work for them otherwise we should declare CGN Historic from day one. Keith --Apple-Mail-33-987619093 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = 2/7/2011 3:39 PM, Brian E Carpenter wrote:
On= 2011-02-08 10:09, Jack Bates wrote:
...
3) Implementers of CGN/LSN/Provider NAT that support 6to4 = anycast should
implement NPTv6 to convert the = 2002:: addresses inbound from = IPv4
anycast to local IPv6 = addresses.

I think it's = too soon to include that in operational advice; who = knows
whether NPT6 will even = be published as an RFC?

Also, this = approach seems to me to be too complex to become = accepted
practice.

I don't really like it, but = it's the only way I've seen to support 6to4 anycast behind CGN. The = fallback is to disallow 6to4. I think it is good to point out an option, = even if we believe it is better to not use 6to4 in such environments. = There are many who won't even think of it.

To = me this seems like it's of such limited applicability that it will never = see actual use.

The correct fallback, of = course, is for ISPs using CGN to:

- provide an = option for their customers who need it to get a native v4 address via = some other means (say by tunneling), and permit 6to4 over that, = and/or
- provide native v6 for all of their customers using = CGN, and encourage their customers to migrate to v6 if CGN doesn't work = for them

otherwise we should declare CGN = Historic from day = one.

Keith

= --Apple-Mail-33-987619093-- From moore@network-heretics.com Mon Feb 7 15:49:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1B93A6FDA for ; Mon, 7 Feb 2011 15:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rGydng6-Fhu for ; Mon, 7 Feb 2011 15:49:07 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id DDCAD3A6FD9 for ; Mon, 7 Feb 2011 15:49:06 -0800 (PST) Received: from [184.212.79.137] (helo=184-212-79-137.pools.spcsdns.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmapQ-0002MN-J2; Mon, 07 Feb 2011 18:49:10 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-34-987764422 From: Keith Moore In-Reply-To: <4D506418.9090706@gmail.com> Date: Mon, 7 Feb 2011 18:49:04 -0500 Message-Id: <7EFD0F3C-7E73-437D-9A6A-955D4EDA6CDF@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505F79.907@brightok.net> <4D506418.9090706@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940b2048194293c25bb2a99d0f2e8216f08350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 184.212.79.137 Cc: IPv6 Operations Subject: Re: [v6ops] AAAA records [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:49:08 -0000 --Apple-Mail-34-987764422 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 7, 2011, at 4:28 PM, Brian E Carpenter wrote: >=20 > On 2011-02-08 10:09, Jack Bates wrote: > ... >>=20 >> 1) If 6to4 Addressing is advertised via AAAA records, publishers = should >> be aware that CGN/LSN/Provider NAT will break customers behind them = from >> utilizing direct 6to4 communications >=20 > Yes, this is a good point. Should we simply recommend against = advertising > *any* 6to4 address in DNS, or at least provide a very strong health = warning? Mumble. AAAA records aren't the problem, the unreliability of = exchanging packets with 6to4 destinations in the face of NATs in the = network is the problem. That problem exists regardless of whether those = 6to4 addresses are advertised in DNS. =20 (I think it's important to clearly distinguish between the problem = statement from any recommendations that might result from that = identified problem.) I would support publishing a carefully tailored warning about using = 6to4. e.g. It is NOT RECOMMENDED to rely on 6to4 addresses for connectivity to = servers intended for general public use, unless=20 a) a 6to4 address is the only kind of public IPv6 address that is = available to that server, OR b) there is a mechanism associated with the protocol(s) used on that = server that makes 6to4 the least preferred option. Examples (and yes, I know this needs work...but hopefully you get the = idea): 1. An IPv4 NAT/IPv6 router that provides Internet connectivity for = several hosts, is assigned a public IPv4 address by its upstream = provider, but has no IPv6 addresses. The router implements NAPT to = provide v4 addresses for the hosts that it supports, and 6to4 to provide = IPv6 addresses for the hosts that it supports. =20 If there is a need for some of those hosts to act as "servers", i.e., to = accept connections which were initiated from outside the router, it is = reasonable for those services to be accessed using the server hosts' = 6to4 addresses. If there is a need for those servers to be advertised = in DNS, it is reasonable to publish AAAA records containing those 6to4 = addresses. 2. An IPv4 NAT/IPv6 router that provides Internet connectivity for = several hosts, is assigned a public IPv4 address by its upstream = provider, and also has an IPv6 /48 block routed to it. The router = implements NAPT to provide v4 addresses for the hosts that it supports, = and provides native connectivity for v6. The router also is configured = to advertise 6to4 addresses to its hosts.=20 It may be advisable in such a case for this network to discourage use of = its 6to4 addresses in favor of native v6 addresses, for its publicly = accessible servers. One way to do this might be to advertise the native = v6 addresses using AAAA records in DNS, but not to expose the 6to4 = addresses in this way. =20 If the servers are only used with specific protocols that use MX or SRV = records, it may be possible to expose the 6to4 addresses of those = servers in a way that minimizes the potential for disruption. For = example, the 6to4 address of a server that is only used for incoming = mail might be exposed as follows: example.com. MX 10 native6.example.com. MX 20 6to4.example.com. native6.example.com. AAAA 2001:1234:5678:abcd::1 6to4.example.com. AAAA 2002:2345:6789:abcd::1 Similar techniques can be used with protocols that use SRV records. 3. A host is assigned a public IPv4 address, and derives a 6to4 address = from that public IPv4 address. The host does not have native IPv6 = connectivity. It may be reasonable for such a host to advertise its 6to4 address using = DNS AAAA records (along with its IPv4 address using DNS A records), = since there is no other public IPv6 address available. Advertising = the 6to4 address will enable connectivity for (a) applications running = on hosts which only have IPv6 connectivity, and (b) applications running = on hosts with both NATted IPv4 and IPv6 connectivity but which cannot = function properly through NAT. =20 However, many application clients can operate over either v4 or v6, = and/or are capable of operating through NAT. Many of these clients also = unilaterally prefer IPv6 addresses (including 6to4 addresses) to IPv4 = addresses, advertising this host's 6to4 address in DNS may cause those = applications to take longer to connect -- or in rare cases, to fail = entirely when they would have worked by connecting via IPv4. One way to work around the problem might be to advertise different DNS = records for different applications. For example: ; all of these domains point to the same host. ; HTTP works fine through NAT, works fine with either v4 or v6 ; most clients can be expected to have some means of fetching web pages = using v4 www.example.com. A 35.69.103.137 ; an app that requires IPv6 v6app.example.com. AAAA 2002:2345:6789:abcd::1 ; for logging into the host ssh.example.com. AAAA 2002:2345:6789:abcd::1 A 35.69.103.137 4. A host is assigned a public IPv4 address, and derives a 6to4 address = from that public IPv4 address. The host also has native IPv6 = connectivity. In this case, the only situation in which 6to4 addresses will be the = best destination addresses for some client is when that client is also = using 6to4. If the applications supported by the servers on this host = can also use IPv4 (NATted or not such as is available to that client), = it makes sense to advertise only the public v4 address and the public v6 = address in DNS, as there is a very marginal benefit at best to such = clients connecting via a 6to4 address. Again, if there are a variety of services supported by such a host, with = different degrees of NAT / v4 / v6 tolerance, it may make sense to = advertise different DNS records for different services. --Apple-Mail-34-987764422 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 2011-02-08 10:09, = Jack Bates wrote:
...

1) If 6to4 = Addressing is advertised via AAAA records, publishers = should
be aware that = CGN/LSN/Provider NAT will break customers behind them = from
utilizing direct 6to4 = communications

Yes, this is a good point. Should we = simply recommend against advertising
*any* 6to4 address in DNS, or at = least provide a very strong health = warning?

Mumble.  AAAA records = aren't the problem, the unreliability of exchanging packets with 6to4 = destinations in the face of NATs in the network is the problem. =  That problem exists regardless of whether those 6to4 addresses are = advertised in DNS.   

(I think it's = important to clearly distinguish between the problem statement from any = recommendations that might result from that identified = problem.)

I would support publishing a = carefully tailored warning about using 6to4. =  e.g.

It is NOT RECOMMENDED to rely on = 6to4 addresses for connectivity to servers intended for general public = use, unless 

a) a 6to4 address is the only = kind of public IPv6 address that is available to that server, = OR
b) there is a mechanism associated with the protocol(s) = used on that server that makes 6to4 the least preferred = option.

Examples (and yes, I know this needs = work...but hopefully you get the = idea):

1. An IPv4 NAT/IPv6 router that = provides Internet connectivity for several hosts, is assigned a public = IPv4 address by its upstream provider, but has no IPv6 addresses. =  The router implements NAPT to provide v4 addresses for the hosts = that it supports, and 6to4 to provide IPv6 addresses for the hosts that = it supports.   

If there is a = need for some of those hosts to act as "servers", i.e., to accept = connections which were initiated from outside the router, it is = reasonable for those services to be accessed using the server hosts' = 6to4 addresses.  If there is a need for those servers to be = advertised in DNS, it is reasonable to publish AAAA records containing = those 6to4 addresses.

2.  An IPv4 = NAT/IPv6 router that provides Internet connectivity for several hosts, = is assigned a public IPv4 address by its upstream provider, and also has = an IPv6 /48 block routed to it.  The router implements NAPT to = provide v4 addresses for the hosts that it supports, and provides native = connectivity for v6.  The router also is configured to advertise = 6to4 addresses to its hosts. 

It may = be advisable in such a case for this network to discourage use of its = 6to4 addresses in favor of native v6 addresses, for its publicly = accessible servers.  One way to do this might be to advertise the = native v6 addresses using AAAA records in DNS, but not to expose the = 6to4 addresses in this way.    

If = the servers are only used with specific protocols that use MX or SRV = records, it may be possible to expose the 6to4 addresses of those = servers in a way that minimizes the potential for disruption.  For = example, the 6to4 address of a server that is only used for incoming = mail might be exposed as follows:

<= div>   =             MX   20 6to4.example.com.

native6.example.com.  AAAA = 2001:1234:5678:abcd::1
6to4.example.com.     = AAAA 2002:2345:6789:abcd::1

3. A host is = assigned a public IPv4 address, and derives a 6to4 address from that = public IPv4 address.  The host does not have native IPv6 = connectivity.

It may be reasonable for such = a host to advertise its 6to4 address using DNS AAAA records (along with = its IPv4 address using DNS A records), since there is no other public = IPv6 address available.    Advertising the 6to4 address will = enable connectivity for (a) applications running on hosts which only = have IPv6 connectivity, and (b) applications running on hosts with both = NATted IPv4 and IPv6 connectivity but which cannot function properly = through NAT.  

However, many application = clients can operate over either v4 or v6, and/or are capable of = operating through NAT.  Many of these clients also unilaterally = prefer IPv6 addresses (including 6to4 addresses) to IPv4 addresses, = advertising this host's 6to4 address in DNS may cause those applications = to take longer to connect -- or in rare cases, to fail entirely when = they would have worked by connecting via = IPv4.

One way to work around the problem might = be to advertise different DNS records for different applications. =  For example:

; all of these domains point = to the same host.
; HTTP works fine through NAT, works fine with either = v4 or v6
; most clients can be expected to have some means of = fetching web pages using v4

www.example.com.    =   A     35.69.103.137

; an app that requires = IPv6

v6app.example.com.   =  AAAA  2002:2345:6789:abcd::1
; for logging into the = host

ssh.example.com.     =  AAAA  2002:2345:6789:abcd::1
   =                    A =     35.69.103.137

4. A = host is assigned a public IPv4 address, and derives a 6to4 address from = that public IPv4 address.  The host also has native IPv6 = connectivity.

In this case, the only = situation in which 6to4 addresses will be the best destination addresses = for some client is when that client is also using 6to4.    If = the applications supported by the servers on this host can also use IPv4 = (NATted or not such as is available to that client), it makes sense to = advertise only the public v4 address and the public v6 address in DNS, = as there is a very marginal benefit at best to such clients connecting = via a 6to4 address.

Again, if there are a = variety of services supported by such a host, with different degrees of = NAT / v4 / v6 tolerance, it may make sense to advertise different DNS = records for different = services.




= --Apple-Mail-34-987764422-- From randy@psg.com Mon Feb 7 15:58:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921ED3A6EA0 for ; Mon, 7 Feb 2011 15:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGEklMM3FWz3 for ; Mon, 7 Feb 2011 15:58:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id BB87D3A6E77 for ; Mon, 7 Feb 2011 15:58:47 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pmayo-000KBK-Kq; Mon, 07 Feb 2011 23:58:50 +0000 Date: Mon, 07 Feb 2011 15:58:50 -0800 Message-ID: From: Randy Bush To: "Templin, Fred L" In-Reply-To: References: <4D4A2401.2020500@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] Out of scope discussion [Fwd:I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:58:48 -0000 >> 6rd is just one more in a long line of hacks to allow somone running >> windows at home to pretend that their provider is giving them ipv6 >> transport when, in fact, they do not. > > Then, long live IRON! one more in a long line of bad whitewash From jbates@brightok.net Mon Feb 7 16:07:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7B23A6FD3 for ; Mon, 7 Feb 2011 16:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Flze+OoM7o6O for ; Mon, 7 Feb 2011 16:07:19 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id D6B353A6FCF for ; Mon, 7 Feb 2011 16:07:18 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p1807LQ3010356; Mon, 7 Feb 2011 18:07:21 -0600 (CST) Message-ID: <4D508936.90805@brightok.net> Date: Mon, 07 Feb 2011 18:07:18 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505F79.907@brightok.net> <4D5066A2.9020207@gmail.com> <4D50811E.7080905@brightok.net> <1CD9F144-5AF6-4601-B558-F06CF4716830@network-heretics.com> In-Reply-To: <1CD9F144-5AF6-4601-B558-F06CF4716830@network-heretics.com> Content-Type: multipart/alternative; boundary="------------000709090606020608090102" Cc: IPv6 Operations , =?ISO-8859-1?Q?R=E9m?= Subject: Re: [v6ops] NPTv6 [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 00:07:19 -0000 This is a multi-part message in MIME format. --------------000709090606020608090102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/7/2011 5:46 PM, Keith Moore wrote: > The correct fallback, of course, is for ISPs using CGN to: > > - provide an option for their customers who need it to get a native v4 > address via some other means (say by tunneling), and permit 6to4 over > that, and/or All customers need IPv6 access. Not all customers can have a native IPv4 address. In some cases, it is possible that 6to4 will be the only option available. > - provide native v6 for all of their customers using CGN, and > encourage their customers to migrate to v6 if CGN doesn't work for them > It isn't a matter of migrating customers by their choice. It is a matter of providing them IPv6 connectivity any way possible and maintaining some IPv4 connectivity. Both stacks need to be reachable, even if in a limited state. 6to4 is an unideal transition mechanism and shouldn't be used if possible, but there are cases (as it is currently the most deployed) where 6to4 will be the only mechanism. > otherwise we should declare CGN Historic from day one. > You can't declare CGN Historic if there is no other way to allow IPv4 connectivity with the absence of unique IPv4 addresses. As an ISP, I don't like the options any more than you do. However, my job is to provide all customers access to both IPv4 and IPv6 content that they might wish to reach to the best of my ability. Like most ISPs, there is a separation between the technical architecture of the network and the people who decide on what equipment to buy and when. As such, there will be different levels of connectivity depending on the location, but ALL locations will have basic (customers want http connectivity most) connectivity to both protocols with focus first on IPv6 connectivity. Jack --------------000709090606020608090102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/7/2011 5:46 PM, Keith Moore wrote:
 
The correct fallback, of course, is for ISPs using CGN to:

- provide an option for their customers who need it to get a native v4 address via some other means (say by tunneling), and permit 6to4 over that, and/or

All customers need IPv6 access. Not all customers can have a native IPv4 address. In some cases, it is possible that 6to4 will be the only option available.

- provide native v6 for all of their customers using CGN, and encourage their customers to migrate to v6 if CGN doesn't work for them


It isn't a matter of migrating customers by their choice. It is a matter of providing them IPv6 connectivity any way possible and maintaining some IPv4 connectivity. Both stacks need to be reachable, even if in a limited state. 6to4 is an unideal transition mechanism and shouldn't be used if possible, but there are cases (as it is currently the most deployed) where 6to4 will be the only mechanism.

otherwise we should declare CGN Historic from day one.

You can't declare CGN Historic if there is no other way to allow IPv4 connectivity with the absence of unique IPv4 addresses. As an ISP, I don't like the options any more than you do. However, my job is to provide all customers access to both IPv4 and IPv6 content that they might wish to reach to the best of my ability. Like most ISPs, there is a separation between the technical architecture of the network and the people who decide on what equipment to buy and when. As such, there will be different levels of connectivity depending on the location, but ALL locations will have basic (customers want http connectivity most) connectivity to both protocols with focus first on IPv6 connectivity.


Jack
--------------000709090606020608090102-- From jbates@brightok.net Mon Feb 7 16:14:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97543A6FD3 for ; Mon, 7 Feb 2011 16:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nrfj7gXZe7Vr for ; Mon, 7 Feb 2011 16:14:26 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id C36743A6E77 for ; Mon, 7 Feb 2011 16:14:26 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p180ENj6012090; Mon, 7 Feb 2011 18:14:24 -0600 (CST) Message-ID: <4D508ADD.8060601@brightok.net> Date: Mon, 07 Feb 2011 18:14:21 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Smith References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <20110208070348.2fedcfea@opy.nosense.org> In-Reply-To: <20110208070348.2fedcfea@opy.nosense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 00:14:27 -0000 On 2/7/2011 2:33 PM, Mark Smith wrote: > Part of > that advice could be that ISPs are encouraged to operate their on 6to4 > relays as soon as they get native IPv6 transit, and for them to > consider the 6to4 relay another production level service, so that they > consider it's availability requirements to be the same as their DNS, > mail etc. As long as they do a proper job of it, I think deploying a > 6to4 relay is a relatively easy first step for an ISP to start > presenting some IPv6 services to their customers. We established a HE tunnel specifically to handle a 6to4 relay years ago. Sprint was advertising one via BGP and it had several IPv6 connectivity issues. Offering it ourselves allowed for easier support and better customer experience. Jack From Fred.L.Templin@boeing.com Mon Feb 7 16:15:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7373A6FE2 for ; Mon, 7 Feb 2011 16:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMPLul+YJby8 for ; Mon, 7 Feb 2011 16:15:26 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 59B193A6FDE for ; Mon, 7 Feb 2011 16:15:26 -0800 (PST) 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 p180FOfk012770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Feb 2011 16:15:24 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p180FNPX019786; Mon, 7 Feb 2011 16:15:23 -0800 (PST) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p180FMnR019771 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 7 Feb 2011 16:15:22 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Mon, 7 Feb 2011 16:15:22 -0800 From: "Templin, Fred L" To: Randy Bush Date: Mon, 7 Feb 2011 16:15:21 -0800 Thread-Topic: [v6ops] Out of scope discussion [Fwd:I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] Thread-Index: AcvHIvkGfHAjijStTaudOGVrq+UooQAAd5KA Message-ID: References: <4D4A2401.2020500@gmail.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: IPv6 Operations Subject: Re: [v6ops] Out of scope discussion [Fwd:I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 00:15:27 -0000 > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com]=20 > Sent: Monday, February 07, 2011 3:59 PM > To: Templin, Fred L > Cc: Brian E Carpenter; IPv6 Operations > Subject: Re: [v6ops] Out of scope discussion [Fwd:I-D=20 > Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] >=20 > >> 6rd is just one more in a long line of hacks to allow=20 > somone running > >> windows at home to pretend that their provider is giving them ipv6 > >> transport when, in fact, they do not. > >=20 > > Then, long live IRON! >=20 > one more in a long line of bad whitewash No sir - this is a for-real service that owns up to the difficulties faced by others you've named and fixes them. Fred= From jbates@brightok.net Mon Feb 7 16:33:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4374B3A6EAC for ; Mon, 7 Feb 2011 16:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOMru9uyAKGh for ; Mon, 7 Feb 2011 16:33:24 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 5EC953A6B0A for ; Mon, 7 Feb 2011 16:33:24 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p180XLV5016587; Mon, 7 Feb 2011 18:33:21 -0600 (CST) Message-ID: <4D508F4E.6080009@brightok.net> Date: Mon, 07 Feb 2011 18:33:18 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Templin, Fred L" References: <4D4A2401.2020500@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Out of scope discussion [Fwd:I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 00:33:25 -0000 On 2/7/2011 6:15 PM, Templin, Fred L wrote: > No sir - this is a for-real service that owns up to the > difficulties faced by others you've named and fixes them. Which $50 CPEs are currently supporting IRON? Jack From fred@cisco.com Mon Feb 7 19:50:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 526C33A6BF4 for ; Mon, 7 Feb 2011 19:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.448 X-Spam-Level: X-Spam-Status: No, score=-110.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEUBsCYUd8Zi for ; Mon, 7 Feb 2011 19:50:58 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 65FCA3A6C06 for ; Mon, 7 Feb 2011 19:50:58 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQGADdMUE2rR7H+/2dsb2JhbACCSZRDhgMBiBhzoC2bIIVaBIR6hm2DLg Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2011 03:51:04 +0000 Received: from Freds-Computer.local (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p183owH0012080 for ; Tue, 8 Feb 2011 03:51:04 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 07 Feb 2011 19:51:04 -0800 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 07 Feb 2011 19:51:04 -0800 From: Fred Baker Date: Mon, 7 Feb 2011 19:50:49 -0800 Message-Id: To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Content-Type: multipart/alternative; boundary=Apple-Mail-380-1002270022 Subject: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 03:50:59 -0000 --Apple-Mail-380-1002270022 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Question for the assembled throng: We have been having an active = discussion for the past coupe of weeks on Happy Eyeballs. What do people = want to see happen in draft-wing-v6ops-happy-eyeballs-ipv6? I presume = that we need an updated draft, and I have invited the posting of = draft-ietf-v6ops-happy-eyeballs-ipv6.=20 I think the most important question is: what needs to be done before we = decide we are done with this draft? Note that there is a corollary draft = in bmwg, which could probably also use your comments.=20 http://tools.ietf.org/html/draft-baker-bmwg-testing-eyeball-happiness "Testing Eyeball Happiness", Fred Baker= --Apple-Mail-380-1002270022 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Question for the assembled throng: We = have been having an active discussion for the past coupe of weeks on = Happy Eyeballs. What do people want to see happen in = draft-wing-v6ops-happy-eyeballs-ipv6? I presume that we need an updated = draft, and I have invited the posting = of draft-ietf-v6ops-happy-eyeballs-ipv6. 

I think = the most important question is: what needs to be done before we decide = we are done with this draft? Note that there is a corollary draft = in bmwg, which could probably also use your = comments. 

  "Testing Eyeball = Happiness", Fred Baker
= --Apple-Mail-380-1002270022-- From Ted.Lemon@nominum.com Mon Feb 7 20:11:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E61E3A6C85 for ; Mon, 7 Feb 2011 20:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9X9lAPoONSX for ; Mon, 7 Feb 2011 20:11:23 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 184873A6C79 for ; Mon, 7 Feb 2011 20:11:22 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTVDCcFIfBby/WuUpavnUv3biPLdD78Iq@postini.com; Mon, 07 Feb 2011 20:11:29 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E74601B8308 for ; Mon, 7 Feb 2011 20:11:27 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CCA20190052; Mon, 7 Feb 2011 20:11:27 -0800 (PST) (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; Mon, 7 Feb 2011 20:11:27 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Mon, 7 Feb 2011 23:11:22 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> References: To: Fred Baker X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 04:11:24 -0000 The next step is for the working group to adopt it (IMHO). And then = Section 4.2.4 needs to be updated or deleted, and a security = considerations section needs to be added, which would require some = thought. I would like to see all the references to threads taken out of section = 4.1, because you don't need threads to implement happy eyeballs. It = should just be stated in terms of scheduling of events and receipt of = results. I've already stated a preference for a non-heuristic solution, where you = just try everything at once. I think a heuristic solution that tracks = past performance is going to be difficult to implement, and ultimately = won't see wide implementation. However, I realize that there are = strong arguments in favor of using heuristics as well. I don't think = we came to any consensus on this point. One way or another, we ought to try to make progress on this work. From cb.list6@gmail.com Mon Feb 7 20:41:54 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AE8C3A6C99 for ; Mon, 7 Feb 2011 20:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcFCshheBltR for ; Mon, 7 Feb 2011 20:41:53 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 802EB3A6C86 for ; Mon, 7 Feb 2011 20:41:53 -0800 (PST) Received: by qyk34 with SMTP id 34so91156qyk.10 for ; Mon, 07 Feb 2011 20:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zB94We9CvbR5bR7qOphnwzZR0hZZp75Ud1jPNCa1QkM=; b=h/eFH8/vTTaxIVHRWf45rXYVOOjGwqjNa6AJnp7LNR4sBUJgWPC3ZuxZX/vX65j9s1 tMs3eyeDwP1mGopmKb+MWnbWdCfB8Ra1lB2HKUfjBXISNMLEFYgd5l+wSLQkS5tc6kIB YIU6xWN731MYNtA6Sr7nuAWM6g3cqoq3yhgJg= 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=YWQZa7Zpm/+vXXnAc4qxJFRqCqY/WfcdGthx368mfJ8y13bl7zidmOomb55Z6jhIZt JuFwNv/FOjTKfySh3Q6i4UBBCV79mwE6CHpufh0BUJoq5SqGRB8Z0dbEYnU8oYNv3QaP ItXhjvLRGGnmZV0JUrwUAG3Q2yw+TA4bz4/Fg= MIME-Version: 1.0 Received: by 10.229.90.196 with SMTP id j4mr13337251qcm.144.1297140118958; Mon, 07 Feb 2011 20:41:58 -0800 (PST) Received: by 10.229.224.79 with HTTP; Mon, 7 Feb 2011 20:41:58 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Feb 2011 20:41:58 -0800 Message-ID: From: Cameron Byrne To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 04:41:54 -0000 On Mon, Feb 7, 2011 at 7:50 PM, Fred Baker wrote: > Question for the assembled throng: We have been having an active discussi= on > for the past coupe of weeks on Happy Eyeballs. What do people want to see > happen in draft-wing-v6ops-happy-eyeballs-ipv6? I presume that we need an > updated draft, and I have invited the posting > of=A0draft-ietf-v6ops-happy-eyeballs-ipv6. > I think the most important question is: what needs to be done before we > decide we are done with this draft? Note that=A0there is a corollary draf= t in Is it possible that happy eyeballs is not feasible to implement within the short time frame that it may be useful? A few weeks back there was a lively implementation discussion. I am not an expert in this area, but it looked like there was a lot of disagreement to me. We don't have to agree on how to implement it, but it would be interesting to know the level of confidence that i can and will be implemented. I personally do not care for these happyeyeballs issues ... i find the problem set further entrenches me into the single stack camp. Cameron From moore@network-heretics.com Mon Feb 7 21:14:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8B43A6C95 for ; Mon, 7 Feb 2011 21:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-d+gO+mJnBC for ; Mon, 7 Feb 2011 21:14:12 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 106743A6C94 for ; Mon, 7 Feb 2011 21:14:12 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Pmfu4-0003Rh-Eq; Tue, 08 Feb 2011 00:14:17 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D508936.90805@brightok.net> Date: Tue, 8 Feb 2011 00:14:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6D495425-E446-4B49-81EA-B22F7CC2A956@network-heretics.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505F79.907@brightok.net> <4D5066A2.9020207@gmail.com> <4D50811E.7080905@brightok.net> <1CD9F144-5AF6-4601-B558-F06CF4716830@network-heretics.com> <4D508936.90805@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94046867ef300cdf6568a1d121ae937f607350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: IPv6 Operations Subject: Re: [v6ops] NPTv6 [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 05:14:13 -0000 On Feb 7, 2011, at 7:07 PM, Jack Bates wrote: > On 2/7/2011 5:46 PM, Keith Moore wrote: >>=20 >> =20 >> The correct fallback, of course, is for ISPs using CGN to: >>=20 >> - provide an option for their customers who need it to get a native = v4 address via some other means (say by tunneling), and permit 6to4 over = that, and/or >=20 > All customers need IPv6 access. Not all customers can have a native = IPv4 address. In some cases, it is possible that 6to4 will be the only = option available. I can't disagree with that. >> - provide native v6 for all of their customers using CGN, and = encourage their customers to migrate to v6 if CGN doesn't work for them >>=20 >=20 > It isn't a matter of migrating customers by their choice. It is a = matter of providing them IPv6 connectivity any way possible and = maintaining some IPv4 connectivity. Both stacks need to be reachable, = even if in a limited state. 6to4 is an unideal transition mechanism and = shouldn't be used if possible, but there are cases (as it is currently = the most deployed) where 6to4 will be the only mechanism. All of the transition mechanisms, including dual stack, are "unideal" in = some ways. There are cases where 6to4 works fairly well and cases = where it works less well. It makes sense to document those cases. =20 Also, in the cases where the network gratuitously breaks 6to4 because of = misconfiguration, it's worthwhile to try to identify and fix these = problems. Operators are still gaining experience with 6to4 and there = is some possibility that the situation will improve over time. I don't = see how this is inherently different than, say, identifying sources of = bogus BGP advertisements in v4. >> otherwise we should declare CGN Historic from day one. >>=20 > You can't declare CGN Historic if there is no other way to allow IPv4 = connectivity with the absence of unique IPv4 addresses. It's not like CGN is the only way to offer IPv4 connectivity. It's not = like all 2**32 IPv4 addresses are actually assigned to hosts or routers. = There are lots of ways to better utilize IPv4 addresses. Sure they're = ugly. There are tradeoffs between the amount of burden to put on = networks and the amount of burden to put on applications. (Not = surprisingly network operators tend to gloss over the needs of = applications and focus on their own needs.) But honestly I don't have much of a problem with ISPs giving CGN to = customers, especially those who aren't significantly harmed by it . = IPv4 is nearing EOL, and many customers are NATing all of their hosts = anyway. But I do think it's incumbent on those ISPs to offer either = some way of getting native v4, or some IPv6 solution, to those = customers. To me this is an architectural principle of "don't paint = yourself into a corner", or maybe (to use a flying analogy) "don't fly = so far up into a narrow canyon that you can't turn around within the = canyon's width". CGN makes some sense as a stopgap measure, but only if = it also provides a way out of the mess - or alternatively, if a way out = is provided along with CGN. Keith From moore@network-heretics.com Mon Feb 7 21:20:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6263A6C9C for ; Mon, 7 Feb 2011 21:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJLGgTm+55r5 for ; Mon, 7 Feb 2011 21:20:36 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id D9F573A6C95 for ; Mon, 7 Feb 2011 21:20:35 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Pmg0G-0003rM-K2; Tue, 08 Feb 2011 00:20:40 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D50474D.3030406@brightok.net> Date: Tue, 8 Feb 2011 00:20:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <01C8F6CB-5F36-4974-8F3F-B02FAC37D210@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940e91ee4d1508b55df39806c18d502978a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 05:20:36 -0000 On Feb 7, 2011, at 2:26 PM, Jack Bates wrote: > On 2/7/2011 1:20 PM, Fred Baker wrote: >>=20 >> I'm very confused. If you are using NPTv6, you have native IPv6 >> service. If you have native IPv6 service, why on earth would you be >> using 6to4? >=20 > I can NAT66 from 2002:: prefixes to my native prefixes (I have native = IPv6 at all ISP 6to4 relays). yes, but then you're providing v6 service that's about as broken as v4 = service with CGN. please don't do that. v6 should be NAT free. Keith From moore@network-heretics.com Mon Feb 7 21:22:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FF83A7018 for ; Mon, 7 Feb 2011 21:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYXNGTcBIZGz for ; Mon, 7 Feb 2011 21:22:10 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 3B4473A6C94 for ; Mon, 7 Feb 2011 21:22:10 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Pmg1n-0003KN-8E; Tue, 08 Feb 2011 00:22:15 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-35-1007750750 From: Keith Moore In-Reply-To: Date: Tue, 8 Feb 2011 00:22:10 -0500 Message-Id: <37A32F65-E30A-4E6F-A562-E8447BCA00D8@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> To: Cameron Byrne X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9409f2b92460e6dc9aa30352b69d81200f2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 05:22:11 -0000 --Apple-Mail-35-1007750750 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 7, 2011, at 2:29 PM, Cameron Byrne wrote: > On Mon, Feb 7, 2011 at 10:24 AM, Gert Doering wrote: >> Hi, >>=20 >> On Mon, Feb 07, 2011 at 12:57:49PM -0500, Keith Moore wrote: >>> 6rd is great for ISPs. It doesn't solve the problem for individual = users. >>=20 >> Neither does 6to4 with badly deployed anycast relays. >>=20 >=20 > +1 >=20 > I already null route the anycast address because it cause a mess in my > CGN/NAT tables ... since i use bogon space to my users they think > 6to4 might work. >=20 > Yes... I am the face of the future internet. >=20 if you're bent on breaking standard transition mechanisms you should = expect to lose all of your customers as well as your peers. and good = riddance. make no mistake, what you are doing is completely unacceptable. Keith --Apple-Mail-35-1007750750 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Mon, Feb 7, 2011 at 10:24 AM, Gert Doering <gert@space.net> = wrote:
Hi,

On Mon, Feb 07, = 2011 at 12:57:49PM -0500, Keith Moore wrote:
6rd is great for ISPs.  It = doesn't solve the problem for individual = users.

Neither does = 6to4 with badly deployed anycast relays.


+1

I already null route the = anycast address because it cause a mess in my
CGN/NAT tables ... = since i use bogon space to  my users they think
6to4 might = work.

Yes... I am the face of the future internet.


if = you're bent on breaking standard transition mechanisms you should expect = to lose all of your customers as well as your peers.   and good = riddance.

make no mistake, what you are doing = is completely = unacceptable.

Keith

= --Apple-Mail-35-1007750750-- From moore@network-heretics.com Mon Feb 7 21:23:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A9A3A701C for ; Mon, 7 Feb 2011 21:23:41 -0800 (PST) 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_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVFLQgxayJJL for ; Mon, 7 Feb 2011 21:23:40 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id A16513A7016 for ; Mon, 7 Feb 2011 21:23:40 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Pmg3F-0005ic-Ff; Tue, 08 Feb 2011 00:23:45 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D50490F.4070500@brightok.net> Date: Tue, 8 Feb 2011 00:23:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940ceab8e4a314cbed8e1f81d8e30b52e72350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 05:23:41 -0000 On Feb 7, 2011, at 2:33 PM, Jack Bates wrote: > On 2/7/2011 1:23 PM, Keith Moore wrote: >> Since when were arguments of the form "this will break things that >> people need" out of scope? >=20 > When it's already been recognized that those things will break and no = one is providing a good solution, or people ignore the already existing = solutions. >=20 > Given implementation time frames, the best v6ops can hope for is to = clarify on current problems and currently implemented available = solutions to make things as interoperable as possible; accepting that = there are some problems we just can't fix (as some are IPv4 problems = which happen to effect some of the IPv6 transition tools). strongly disagree. there's a very real risk that CGN will thwart the ability to transition = to IPv6. it may need a mercy killing. Keith From moore@network-heretics.com Mon Feb 7 21:44:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C643A6C9A for ; Mon, 7 Feb 2011 21:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhHdvBamNAW2 for ; Mon, 7 Feb 2011 21:44:56 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id DC05F3A6FEF for ; Mon, 7 Feb 2011 21:44:53 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmgNZ-0001DA-Br; Tue, 08 Feb 2011 00:44:46 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> Date: Tue, 8 Feb 2011 00:44:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940c5a252274b1799e5aa2f6584c6ccabb2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 05:44:58 -0000 On Feb 7, 2011, at 2:11 PM, Fred Baker wrote: > If I can summarize Keith's concern with 6rd, it is not that it doesn't = deploy an IPv6-capable service; it is that the service has a smaller = Path MTU than the native MTU of links he uses, often has a broken PMTU = implementation due to ICMPv6 filtering, and is not native. If I can = summarize the views of those using it (such as a Dutch provider I spoke = with Wednesday in London), it's not that they don't want or expect to = deploy a native IPv6 service, it's that they want to deploy an IPv6 = service now and have infrastructure that they can't immediately upgrade = (such as, in the Dutch case I mentioned, a service network that they = have to use that is IPv4-only for the foreseeable future). If by "Keith" you mean me, I can acknowledge all of those concerns, but = overall I like 6rd (for the reasons you cite). My problem with 6rd is = that it's not something than an individual user who needs IPv6 can = deploy independently of support from his ISP. 6to4 is such a mechanism, = and that's it's great virtue. =20 Of course, as IPv4 becomes more and more broken, 6to4 can be expected to = work less and less well, just like the rest of the IPv4 internet. = That's inevitable. Really I see two major problems: 1. ISPs that want to impose CGNs on their customers before providing = them any way to use v6 at all. The CGN breaks 6to4 and there is no = suitable replacement. 2. Users connect to the Internet via a wide variety of means - local = Ethernet, wireless WAN, cell modem, hotel networks, Starbucks, etc., and = typically they get those services from a variety of providers. So just = because an ISP provides a means to allow its customers to use v6 doesn't = mean that customer's problems are solved. The customer needs a = predictable way to get to "the (IPv6) net" via all of these, or at least = most of them. (though I do find that with a good cell modem, I need to = connect to random networks much less frequently than before...) Regarding IRON, I expect that it's biggest problem is that it's way = behind on the deployment curve. That doesn't mean it's not worth = considering of course, though one wonders how many of the myriad = different possible transition mechanisms we need to implement. Keith From cb.list6@gmail.com Mon Feb 7 21:56:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44CDF3A6FEF for ; Mon, 7 Feb 2011 21:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZNcJEDzPmYS for ; Mon, 7 Feb 2011 21:56:38 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 236EA3A6C9A for ; Mon, 7 Feb 2011 21:56:37 -0800 (PST) Received: by qwi2 with SMTP id 2so4158531qwi.31 for ; Mon, 07 Feb 2011 21:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=p5B8F56UsOOJig/Wezc9GJHsNZwH/KUdLsKtC81cJjI=; b=fC36dCReMH0+/0OcFYa8m0rP9ElXycnz+1V4VgQeNosUFO/vCc+ldFPAkCfpTWVOum mU4xcT7DVDb9443hQHIOYrZiPRS5S5C36Y+MoT/H7qIha2q+fEFeh8xh8dto2FvEQT6a zpXgoxdNuk9ImiYIBLtqobgGa/6jCpor+fazM= 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=XebHARykhTb50sSWdEJjJ0jHpki7kMHffc11d+jMrT2LqLGHu7oFUleVGwhmhQRxWd wf1nci03LF3lc4oDjL2qsYT5CvegVaedGaUGA75foSId7eTxvtHWWXB/11c/v3UVNCvD kYSTObPm3+ReEl4H7q49cu/D6fmg4h4XiUnLA= MIME-Version: 1.0 Received: by 10.229.90.196 with SMTP id j4mr13374295qcm.144.1297144603291; Mon, 07 Feb 2011 21:56:43 -0800 (PST) Received: by 10.229.224.79 with HTTP; Mon, 7 Feb 2011 21:56:43 -0800 (PST) Received: by 10.229.224.79 with HTTP; Mon, 7 Feb 2011 21:56:43 -0800 (PST) In-Reply-To: <37A32F65-E30A-4E6F-A562-E8447BCA00D8@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <37A32F65-E30A-4E6F-A562-E8447BCA00D8@network-heretics.com> Date: Mon, 7 Feb 2011 21:56:43 -0800 Message-ID: From: Cameron Byrne To: Keith Moore Content-Type: multipart/alternative; boundary=0016363106494d2f65049bbf03f9 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 05:56:39 -0000 --0016363106494d2f65049bbf03f9 Content-Type: text/plain; charset=ISO-8859-1 On Feb 7, 2011 9:22 PM, "Keith Moore" wrote: > > > On Feb 7, 2011, at 2:29 PM, Cameron Byrne wrote: > >> On Mon, Feb 7, 2011 at 10:24 AM, Gert Doering wrote: >>> >>> Hi, >>> >>> >>> On Mon, Feb 07, 2011 at 12:57:49PM -0500, Keith Moore wrote: >>>> >>>> 6rd is great for ISPs. It doesn't solve the problem for individual users. >>> >>> >>> Neither does 6to4 with badly deployed anycast relays. >>> >>> >> >> +1 >> >> I already null route the anycast address because it cause a mess in my >> CGN/NAT tables ... since i use bogon space to my users they think >> 6to4 might work. >> >> Yes... I am the face of the future internet. >> > > if you're bent on breaking standard transition mechanisms you should expect to lose all of your customers as well as your peers. and good riddance. > > make no mistake, what you are doing is completely unacceptable. > Interesting statement. Cb > Keith > --0016363106494d2f65049bbf03f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Feb 7, 2011 9:22 PM, "Keith Moore" <moore@network-heretics.com> wrote:
>
>
> On Feb 7, 2011, at 2:29 PM, Cameron Byrne wrote:
>
>> On Mon, Feb 7, 2011 at 10:24 AM, Gert Doering <gert@space.net> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On Mon, Feb 07, 2011 at 12:57:49PM -0500, Keith Moore wrote: >>>>
>>>> 6rd is great for ISPs. =A0It doesn't solve the problem= for individual users.
>>>
>>>
>>> Neither does 6to4 with badly deployed anycast relays.
>>>
>>>
>>
>> +1
>>
>> I already null route the anycast address because it cause a mess i= n my
>> CGN/NAT tables ... since i use bogon space to =A0my users they thi= nk
>> 6to4 might work.
>>
>> Yes... I am the face of the future internet.
>>
>
> if you're bent on breaking standard transition mechanisms you shou= ld expect to lose all of your customers as well as your peers. =A0 and good= riddance.
>
> make no mistake, what you are doing is completely unacceptable.
>

Interesting statement.

Cb
> Keith
>

--0016363106494d2f65049bbf03f9-- From joelja@bogus.com Mon Feb 7 22:22:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33AAF3A6B69 for ; Mon, 7 Feb 2011 22:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMZ6CpcWdtuZ for ; Mon, 7 Feb 2011 22:22:18 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id B13753A7018 for ; Mon, 7 Feb 2011 22:22:17 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p186MGn6047181 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 8 Feb 2011 06:22:17 GMT (envelope-from joelja@bogus.com) Message-ID: <4D50E118.5010203@bogus.com> Date: Mon, 07 Feb 2011 22:22:16 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <37A32F65-E30A-4E6F-A562-E8447BCA00D8@network-heretics.com> In-Reply-To: <37A32F65-E30A-4E6F-A562-E8447BCA00D8@network-heretics.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Daniel Roesen , v6ops@ietf.org Subject: [v6ops] Moderator input - Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 06:22:19 -0000 On 2/7/11 9:22 PM, Keith Moore wrote: >> I already null route the anycast address because it cause a mess in my >> CGN/NAT tables ... since i use bogon space to my users they think >> 6to4 might work. >> >> Yes... I am the face of the future internet. >> > > if you're bent on breaking standard transition mechanisms you should > expect to lose all of your customers as well as your peers. and good > riddance. > > make no mistake, what you are doing is completely unacceptable. I think we can slightly elevate the civility of this thread. Ad hominem does not have a place in the dicussion of the merits or lack thereof of transition methods or the decisions of individual actors. thanks joel > Keith > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From martin@millnert.se Mon Feb 7 22:24:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C363A7018 for ; Mon, 7 Feb 2011 22:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNmmz8ebeCeo for ; Mon, 7 Feb 2011 22:24:36 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by core3.amsl.com (Postfix) with ESMTP id B9C103A6B69 for ; Mon, 7 Feb 2011 22:24:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 386CB7764; Tue, 8 Feb 2011 07:29:27 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJTXZeU+PVBp; Tue, 8 Feb 2011 07:29:27 +0100 (CET) Received: from [IPv6:2a02:9a0:100:2400::6] (shakira.us.millnert.se [IPv6:2a02:9a0:100:2400::6]) by ncis.csbnet.se (Postfix) with ESMTPSA id 681A1774B; Tue, 8 Feb 2011 07:29:25 +0100 (CET) From: Martin Millnert To: Cameron Byrne In-Reply-To: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> Content-Type: text/plain; charset="UTF-8" Date: Tue, 08 Feb 2011 01:24:35 -0500 Message-ID: <1297146275.4205.14.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 06:24:39 -0000 On Mon, 2011-02-07 at 11:44 -0800, Cameron Byrne wrote: > Nope, and not interested since customers don't care about this 6to4 > service. The only people that care are network admins that have to > deal when it breaks the user or the network. Customers care that > facebook and google and pandora work ... they are generally not > interested in these transport messes, and that is why IPv6 is still > not deployed in MOST place. > > For customers that know what IPv6 is, i have a solution for them, > native IPv6 access, 200 million+ covered people in the USA. > > http://groups.google.com/group/tmoipv6beta > > The days of figuring out transition mechanisms is over. IPv4 is > really exhausted, people need to think about things that are real and > production scale. 6to4 is neither, its more of a hobby than an > infrastructure and the major content players cite 6to4 as a roadblock. > Nobody's fault, just the way it is. > > Your efforts are better spent on rolling out native IPv6 now than > trying to fix something that was built on some pretty naive > assumptions (20-20 hind sight), like that fact that BOGONs would not > be used and IPv4 at the end user would be available in the "IPv4 > end-times". Cameron, I like what you do at TMO. However I can't wrap my head around the logic in what you write here. (If you are null-routing 192.88.99.0/24 for users who are not offered native v6 you are quite possibly part of Google et als brokeness, btw! ) "Content providers think 6to4 is a roadblock to providing IPv6" "Stop trying to make the roadblock go away" "[Having a fully natively enabled IPv6 network for your customers, ...] Your time is better spent playing Sim City than trying to let 6to4 die gently" (my interpretation -- when will sc5 arrive? :) ) I think we agree that the quicker 6to4 can disappear the better, but the way for it to do so is by being replaced by [what the end-users' hosts believe is] native IPv6. I fully agree any operator who has not deployed IPv6 native to all customers yet should not spend time on this draft. But there are those who have, and those who are not operators. Again, 6to4 as a crappy transition mechanism dies by the sword of native IPv6; believing anything else is to not understand the situation IMHO. Presumably, had 6to4 not caused problems/existed, there'd be more content available on IPv6 already, which in theory will drive more IPv6 deployment, which will kill 6to4 even more.. (loop) This draft is a good thing . Cheers, Martin From fred@cisco.com Mon Feb 7 22:30:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66B5F3A701A for ; Mon, 7 Feb 2011 22:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXpllp5jI-Qy for ; Mon, 7 Feb 2011 22:30:33 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BC7083A7018 for ; Mon, 7 Feb 2011 22:30:32 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAHpxUE2rR7Hu/2dsb2JhbACfP4Vpc6AUmyuFWgSEe4Zvgy4 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 08 Feb 2011 06:30:38 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p186UXPC009820; Tue, 8 Feb 2011 06:30:38 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Mon, 07 Feb 2011 22:30:38 -0800 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Mon, 07 Feb 2011 22:30:38 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D50E118.5010203@bogus.com> Date: Mon, 7 Feb 2011 22:30:23 -0800 Message-Id: <1BA5B08D-8C2F-433A-B470-61AC01AB6ED6@cisco.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <37A32F65-E30A-4E6F-A562-E8447BCA00D8@network-heretics.com> <4D50E118.5010203@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Moderator input - Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 06:30:40 -0000 Agreed. Believe me, I have my opinions on all of the issues. But I'm not = certain that today's slugfest accomplished much in any direction. On Feb 7, 2011, at 10:22 PM, Joel Jaeggli wrote: > On 2/7/11 9:22 PM, Keith Moore wrote: >=20 >>> I already null route the anycast address because it cause a mess in = my >>> CGN/NAT tables ... since i use bogon space to my users they think >>> 6to4 might work. >>>=20 >>> Yes... I am the face of the future internet. >>>=20 >>=20 >> if you're bent on breaking standard transition mechanisms you should >> expect to lose all of your customers as well as your peers. and = good >> riddance. >>=20 >> make no mistake, what you are doing is completely unacceptable. >=20 > I think we can slightly elevate the civility of this thread. Ad = hominem > does not have a place in the dicussion of the merits or lack thereof = of > transition methods or the decisions of individual actors. >=20 > thanks > joel >=20 >> Keith >>=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 rogerj@gmail.com Mon Feb 7 22:35:35 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98FA3A702A for ; Mon, 7 Feb 2011 22:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tvRhe1JqvxN for ; Mon, 7 Feb 2011 22:35:34 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 132CF3A7018 for ; Mon, 7 Feb 2011 22:35:33 -0800 (PST) Received: by vxi40 with SMTP id 40so2305538vxi.31 for ; Mon, 07 Feb 2011 22:35:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WgAedGJdgHtV1F/24A0zRaT/uch2IwD7auPhBu8qa8M=; b=DnbaW7Ze9hiLQ+smiCFBfKcSX1l3gCl5cIO9dN6miaxtIvm1Egu2rio6kGsaPIjCLQ LmRw8UW/3WH4QEs0WEK8Qh0WVo0MOtjzBzPpTLFkLeFxQz/qtjxm+mzCCIska8LNmhpb 7aGZxikkQn0waZdx76GHLYzkko0C1XlfEqrwc= 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=uMx/jyp3+D2bl8KreNzxmqrPEm4AbxZu3Tpd286GbR8ze5Xd7sWCPDa78pby/BwopN w/L/D7OMZdz18RBKzFopTxLXSEuOpIEfKxxAVkjfos/pUj8oKRJv/fQtVWbv1UtVQuzq mCxAlGITRe8i+2Nm3KslTLsUjvfGzKpeQ6CMI= MIME-Version: 1.0 Received: by 10.220.187.74 with SMTP id cv10mr4046684vcb.129.1297146938874; Mon, 07 Feb 2011 22:35:38 -0800 (PST) Received: by 10.220.203.137 with HTTP; Mon, 7 Feb 2011 22:35:38 -0800 (PST) In-Reply-To: References: <4D4A2401.2020500@gmail.com> Date: Tue, 8 Feb 2011 07:35:38 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Randy Bush , "Templin, Fred L" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] Out of scope discussion [Fwd:I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 06:35:35 -0000 Please don't start another IRON discussion, I'm just curious so I ask: On Tue, Feb 8, 2011 at 12:58 AM, Randy Bush wrote: >>> 6rd is just one more in a long line of hacks to allow somone running >>> windows at home to pretend that their provider is giving them ipv6 >>> transport when, in fact, they do not. >> >> Then, long live IRON! > > one more in a long line of bad whitewash Randy, Why is IRON such a bad thing? Fred, What good will IRON bring? 10 line (of 80chars) for each of you;) --=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 joelja@bogus.com Mon Feb 7 22:35:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F13A3A702A for ; Mon, 7 Feb 2011 22:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.849 X-Spam-Level: X-Spam-Status: No, score=-101.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_55=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdUiiUx2S8y1 for ; Mon, 7 Feb 2011 22:35:58 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id D60B33A702E for ; Mon, 7 Feb 2011 22:35:57 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p186Zxk2047975 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 8 Feb 2011 06:35:59 GMT (envelope-from joelja@bogus.com) Message-ID: <4D50E44F.60609@bogus.com> Date: Mon, 07 Feb 2011 22:35:59 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Martin Millnert References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> In-Reply-To: <1297146275.4205.14.camel@shakira.millnert.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Daniel Roesen , v6ops@ietf.org, Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 06:35:59 -0000 On 2/7/11 10:24 PM, Martin Millnert wrote: > On Mon, 2011-02-07 at 11:44 -0800, Cameron Byrne wrote: >> Nope, and not interested since customers don't care about this 6to4 >> service. The only people that care are network admins that have to >> deal when it breaks the user or the network. Customers care that >> facebook and google and pandora work ... they are generally not >> interested in these transport messes, and that is why IPv6 is still >> not deployed in MOST place. >> >> For customers that know what IPv6 is, i have a solution for them, >> native IPv6 access, 200 million+ covered people in the USA. >> >> http://groups.google.com/group/tmoipv6beta >> >> The days of figuring out transition mechanisms is over. IPv4 is >> really exhausted, people need to think about things that are real and >> production scale. 6to4 is neither, its more of a hobby than an >> infrastructure and the major content players cite 6to4 as a roadblock. >> Nobody's fault, just the way it is. >> >> Your efforts are better spent on rolling out native IPv6 now than >> trying to fix something that was built on some pretty naive >> assumptions (20-20 hind sight), like that fact that BOGONs would not >> be used and IPv4 at the end user would be available in the "IPv4 >> end-times". > > Cameron, > > I like what you do at TMO. However I can't wrap my head around the > logic in what you write here. (If you are null-routing 192.88.99.0/24 > for users who are not offered native v6 you are quite possibly part of > Google et als brokeness, btw! ) Actually it's pretty simple t-mobile USA's internal nats are using public space(other people's no less) , so your device thinks it actually can use 6to4 if it supports it when in fact that space is somewhere else... my phone currently has the v4 address 26.192.216.111 it doesn't take a genius to figure out whose space that really is... bad idea? definitely. did it seem less bad 10 years ago? probably to someone who doesn't have to live with the consequences... does this have an impact on 6to4? yes it does. > "Content providers think 6to4 is a roadblock to providing IPv6" > "Stop trying to make the roadblock go away" > "[Having a fully natively enabled IPv6 network for your customers, ...] > Your time is better spent playing Sim City than trying to let 6to4 die > gently" (my interpretation -- when will sc5 arrive? :) ) > > I think we agree that the quicker 6to4 can disappear the better, but the > way for it to do so is by being replaced by [what the end-users' hosts > believe is] native IPv6. I fully agree any operator who has not > deployed IPv6 native to all customers yet should not spend time on this > draft. But there are those who have, and those who are not operators. > > Again, 6to4 as a crappy transition mechanism dies by the sword of native > IPv6; believing anything else is to not understand the situation IMHO. > Presumably, had 6to4 not caused problems/existed, there'd be more > content available on IPv6 already, which in theory will drive more IPv6 > deployment, which will kill 6to4 even more.. (loop) > > This draft is a good thing . > > > Cheers, > Martin > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From moore@network-heretics.com Mon Feb 7 22:38:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 010783A702D for ; Mon, 7 Feb 2011 22:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+YQMG7akUM3 for ; Mon, 7 Feb 2011 22:38:01 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 122343A702C for ; Mon, 7 Feb 2011 22:38:01 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmhDB-0005UT-2K; Tue, 08 Feb 2011 01:38:05 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <1297146275.4205.14.camel@shakira.millnert.se> Date: Tue, 8 Feb 2011 01:38:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> To: Martin Millnert X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940354cd2999dcb98d83201d69b44bc417a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: Daniel Roesen , v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 06:38:04 -0000 On Feb 8, 2011, at 1:24 AM, Martin Millnert wrote: > On Mon, 2011-02-07 at 11:44 -0800, Cameron Byrne wrote: >> Nope, and not interested since customers don't care about this 6to4 >> service. The only people that care are network admins that have to >> deal when it breaks the user or the network. Customers care that >> facebook and google and pandora work ... they are generally not >> interested in these transport messes, and that is why IPv6 is still >> not deployed in MOST place. >>=20 >> For customers that know what IPv6 is, i have a solution for them, >> native IPv6 access, 200 million+ covered people in the USA. >>=20 >> http://groups.google.com/group/tmoipv6beta >>=20 >> The days of figuring out transition mechanisms is over. IPv4 is >> really exhausted, people need to think about things that are real and >> production scale. 6to4 is neither, its more of a hobby than an >> infrastructure and the major content players cite 6to4 as a = roadblock. >> Nobody's fault, just the way it is. >>=20 >> Your efforts are better spent on rolling out native IPv6 now than >> trying to fix something that was built on some pretty naive >> assumptions (20-20 hind sight), like that fact that BOGONs would not >> be used and IPv4 at the end user would be available in the "IPv4 >> end-times". >=20 > Cameron, >=20 > I like what you do at TMO. However I can't wrap my head around the > logic in what you write here. (If you are null-routing 192.88.99.0/24 > for users who are not offered native v6 you are quite possibly part of > Google et als brokeness, btw! ) >=20 > "Content providers think 6to4 is a roadblock to providing IPv6" > "Stop trying to make the roadblock go away" > "[Having a fully natively enabled IPv6 network for your customers, = ...] > Your time is better spent playing Sim City than trying to let 6to4 die > gently" (my interpretation -- when will sc5 arrive? :) ) >=20 > I think we agree that the quicker 6to4 can disappear the better, but = the > way for it to do so is by being replaced by [what the end-users' hosts > believe is] native IPv6. I fully agree any operator who has not > deployed IPv6 native to all customers yet should not spend time on = this > draft. But there are those who have, and those who are not operators. >=20 > Again, 6to4 as a crappy transition mechanism dies by the sword of = native > IPv6; believing anything else is to not understand the situation IMHO. > Presumably, had 6to4 not caused problems/existed, there'd be more > content available on IPv6 already, which in theory will drive more = IPv6 > deployment, which will kill 6to4 even more.. (loop) >=20 > This draft is a good thing . I'll be happy for 6to4 to be declared Historic as soon as IPv4 is = declared Historic and native v6 is universally available. I'll be the = first one to toast its demise. Having 6to4 be obsoleted by better service is exactly what success looks = like. Until then, declaring 6to4 Historic is premature. There are still many = valid use cases for it. Sure, some ISPs and content providers don't = like it, but there's no transition scheme that everybody likes. And deliberate denial of service attacks on 6to4 are completely out of = line. Keith From martin@millnert.se Mon Feb 7 22:38:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6B63A702C for ; Mon, 7 Feb 2011 22:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epARjLcB3Hvw for ; Mon, 7 Feb 2011 22:38:04 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by core3.amsl.com (Postfix) with ESMTP id D0F813A7018 for ; Mon, 7 Feb 2011 22:38:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 383377787; Tue, 8 Feb 2011 07:42:56 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4ES62NIhrxV; Tue, 8 Feb 2011 07:42:56 +0100 (CET) Received: from [IPv6:2a02:9a0:100:2400::6] (shakira.us.millnert.se [IPv6:2a02:9a0:100:2400::6]) by ncis.csbnet.se (Postfix) with ESMTPSA id D0EC6774B; Tue, 8 Feb 2011 07:42:54 +0100 (CET) From: Martin Millnert To: Brian E Carpenter In-Reply-To: <4D505931.3010706@gmail.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <89F284E2-934F-4B9C-AB66-AD836F43BC51@network-heretics.com> <1297091215.26424.13.camel@shakira.millnert.se> <1297093176.26424.28.camel@shakira.millnert.se> <4D505931.3010706@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 08 Feb 2011 01:38:05 -0500 Message-ID: <1297147085.4205.24.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 06:38:05 -0000 On Tue, 2011-02-08 at 09:42 +1300, Brian E Carpenter wrote: > Actually, I see his point. The probability in this scenario is that the v4 > path back to the client is actually better than the v6 path, but the problem is > that the client believes it's using IPv6, so it will be quite alarmed > if the SYN/ACK arrives back as an IPv4 packet. > > So it doesn't work, afaics, unless both ends contain this trick. > > Brian That's not what I meant =) The IPv4 connection would only falsely live in the stack itself, as presented to the application layer of the "server". The packets sent back to the client by the server's stack will still be IPv4-packets carrying IPv6 packets in its payload, possibly sourced from 192.88.99.1: 6to4 packets. Since the client is using 6to4, this is the form of packets it expects to get back. But let's scratch and kill my idea here, it has 0 bearing on this discussion, and I regret putting it forth in this time and place. (Any eventual merits of the idea (which is not my own, either) will remain for those who see/understand the utility on doing it, which may or may not make sense in their environment. ) Cheers, Martin From martin@millnert.se Mon Feb 7 22:51:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6599D3A7031 for ; Mon, 7 Feb 2011 22:51:15 -0800 (PST) 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_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjH8AcZeUlYy for ; Mon, 7 Feb 2011 22:51:13 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by core3.amsl.com (Postfix) with ESMTP id 245143A7030 for ; Mon, 7 Feb 2011 22:51:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 5BD377787; Tue, 8 Feb 2011 07:56:06 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Qj1mFeZ8FmE; Tue, 8 Feb 2011 07:56:06 +0100 (CET) Received: from [IPv6:2a02:9a0:100:2400::6] (shakira.us.millnert.se [IPv6:2a02:9a0:100:2400::6]) by ncis.csbnet.se (Postfix) with ESMTPSA id 3101E774B; Tue, 8 Feb 2011 07:56:04 +0100 (CET) From: Martin Millnert To: Joel Jaeggli In-Reply-To: <4D50E44F.60609@bogus.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 08 Feb 2011 01:51:15 -0500 Message-ID: <1297147875.4205.34.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: Daniel Roesen , v6ops@ietf.org, Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 06:51:15 -0000 On Mon, 2011-02-07 at 22:35 -0800, Joel Jaeggli wrote: > On 2/7/11 10:24 PM, Martin Millnert wrote: > > On Mon, 2011-02-07 at 11:44 -0800, Cameron Byrne wrote: > >> Nope, and not interested since customers don't care about this 6to4 > >> service. The only people that care are network admins that have to > >> deal when it breaks the user or the network. Customers care that > >> facebook and google and pandora work ... they are generally not > >> interested in these transport messes, and that is why IPv6 is still > >> not deployed in MOST place. > >> > >> For customers that know what IPv6 is, i have a solution for them, > >> native IPv6 access, 200 million+ covered people in the USA. > >> > >> http://groups.google.com/group/tmoipv6beta > >> > >> The days of figuring out transition mechanisms is over. IPv4 is > >> really exhausted, people need to think about things that are real and > >> production scale. 6to4 is neither, its more of a hobby than an > >> infrastructure and the major content players cite 6to4 as a roadblock. > >> Nobody's fault, just the way it is. > >> > >> Your efforts are better spent on rolling out native IPv6 now than > >> trying to fix something that was built on some pretty naive > >> assumptions (20-20 hind sight), like that fact that BOGONs would not > >> be used and IPv4 at the end user would be available in the "IPv4 > >> end-times". > > > > Cameron, > > > > I like what you do at TMO. However I can't wrap my head around the > > logic in what you write here. (If you are null-routing 192.88.99.0/24 > > for users who are not offered native v6 you are quite possibly part of > > Google et als brokeness, btw! ) > > Actually it's pretty simple t-mobile USA's internal nats are using > public space(other people's no less) , so your device thinks it actually > can use 6to4 if it supports it when in fact that space is somewhere else... > > my phone currently has the v4 address 26.192.216.111 > > it doesn't take a genius to figure out whose space that really is... > > bad idea? definitely. did it seem less bad 10 years ago? probably to > someone who doesn't have to live with the consequences... does this have > an impact on 6to4? yes it does. Right. A gigantic source of brokenness for content providers unfortunately. Try accessing a dual-stacked http-server from a Win7 box connected with a TMO dongle with the above configuration. I expect it to not work very well at all. How many users were behind this configuration, again? I acknowledge that more networks of TMO's size or greater doing this will start pushing OS vendors towards "6to4.default=disabled", because it's an immensely large source of brokenness. If it accomplishes the goal of "6to4.default=disabled" (via Windows Update, etc), great! If it further delays the deployment of IPv6, not as great. I believe MS/Apple has commented on reverting a function in an already-released product, an update in light of this might be of value... James, Christopher? Future IPv4's going to rock. :D Cheers, Martin From moore@network-heretics.com Mon Feb 7 22:57:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4F63A7032 for ; Mon, 7 Feb 2011 22:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr+YFE6-DTnD for ; Mon, 7 Feb 2011 22:57:33 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id DF6CA3A702F for ; Mon, 7 Feb 2011 22:57:32 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmhW4-0005j8-Vg; Tue, 08 Feb 2011 01:57:37 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <1297147875.4205.34.camel@shakira.millnert.se> Date: Tue, 8 Feb 2011 01:57:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1987A727-BD2F-4BAB-AB59-ED27033CE17F@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> <1297147875.4205.34.camel@shakira.millnert.se> To: Martin Millnert X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9403ec027900476db2aeca900dec028a8a8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: Daniel Roesen , v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 06:57:34 -0000 On Feb 8, 2011, at 1:51 AM, Martin Millnert wrote: >>=20 >> Actually it's pretty simple t-mobile USA's internal nats are using >> public space(other people's no less) , so your device thinks it = actually >> can use 6to4 if it supports it when in fact that space is somewhere = else... >>=20 >> my phone currently has the v4 address 26.192.216.111 >>=20 >> it doesn't take a genius to figure out whose space that really is... >>=20 >> bad idea? definitely. did it seem less bad 10 years ago? probably to >> someone who doesn't have to live with the consequences... does this = have >> an impact on 6to4? yes it does. >=20 > Right. A gigantic source of brokenness for content providers > unfortunately. Try accessing a dual-stacked http-server from a Win7 = box > connected with a TMO dongle with the above configuration. I expect it = to > not work very well at all. How many users were behind this > configuration, again? >=20 > I acknowledge that more networks of TMO's size or greater doing this > will start pushing OS vendors towards "6to4.default=3Ddisabled", = because > it's an immensely large source of brokenness. =20 This is a really bizarre statement. An ISP deliberately gives out = addresses to its customers that aren't assigned to said ISP, and when = that breaks things you want to blame the resulting breakage on 6to4? =20 6to4 is not the problem; the problem is breaking fundamental design = assumptions in IP. It's not like 6to4 is the only thing in the v4 = Internet that expects globally scoped addresses to be uniquely assigned = to hosts. > If it accomplishes the goal of "6to4.default=3Ddisabled" (via Windows = Update, etc), great! =20 How is this statement anything other than promoting a denial of service = attack? Keith From joelja@bogus.com Mon Feb 7 23:12:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AAC53A704C for ; Mon, 7 Feb 2011 23:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE+sZZzq9Sxd for ; Mon, 7 Feb 2011 23:12:27 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 8078E3A6C9A for ; Mon, 7 Feb 2011 23:12:20 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p187CK8E049872 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 8 Feb 2011 07:12:21 GMT (envelope-from joelja@bogus.com) Message-ID: <4D50ECD4.60206@bogus.com> Date: Mon, 07 Feb 2011 23:12:20 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Martin Millnert References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> <1297147875.4205.34.camel@shakira.millnert.se> In-Reply-To: <1297147875.4205.34.camel@shakira.millnert.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Daniel Roesen , v6ops@ietf.org, Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 07:12:28 -0000 On 2/7/11 10:51 PM, Martin Millnert wrote: > On Mon, 2011-02-07 at 22:35 -0800, Joel Jaeggli wrote: >> Actually it's pretty simple t-mobile USA's internal nats are using >> public space(other people's no less) , so your device thinks it actually >> can use 6to4 if it supports it when in fact that space is somewhere else... >> >> my phone currently has the v4 address 26.192.216.111 >> >> it doesn't take a genius to figure out whose space that really is... >> >> bad idea? definitely. did it seem less bad 10 years ago? probably to >> someone who doesn't have to live with the consequences... does this have >> an impact on 6to4? yes it does. > > Right. A gigantic source of brokenness for content providers > unfortunately. Try accessing a dual-stacked http-server from a Win7 box > connected with a TMO dongle with the above configuration. I expect it to > not work very well at all. How many users were behind this > configuration, again? that's "are behind" it. T-mobile is not the only one by far e.g. there's no point in singling them out. it's fairly common to find mobile carriers and indeed wireline operators squating on US DOD or uk MOD space. As Fred Baker quipped about the distribution of ipv4 assignments during the bejing ietf, there's a big chunk of the world where users are already living behind huge nats. we can extend that to "and a lot of those nats are aren't in private scope address ranges." The fact of the matter is we ran out of ipv4 addresses a long time ago, and operating assumptions predicated on the assumption of the availability have a tenuous association with the situation as deployed in many cases. From dr@cluenet.de Mon Feb 7 23:31:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 807833A6AE3 for ; Mon, 7 Feb 2011 23:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AX8zb0ZUrsbU for ; Mon, 7 Feb 2011 23:31:24 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 780593A67B6 for ; Mon, 7 Feb 2011 23:31:22 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 02E3610810C; Tue, 8 Feb 2011 08:31:26 +0100 (CET) Date: Tue, 8 Feb 2011 08:31:26 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110208073126.GA18776@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 07:31:25 -0000 On Tue, Feb 08, 2011 at 12:44:41AM -0500, Keith Moore wrote: > My problem with 6rd is that it's not something than an individual > user who needs IPv6 can deploy independently of support from his ISP. > 6to4 is such a mechanism, and that's it's great virtue. That's an illusion. In contrast to 6RD, anycast 6to4 requires the cooperation of both the ISP of the individual user (either to operate a reliable and capacity-wise sufficiently scaled 6to4 relay or make sure there is one reachable for his customers, as well as the cooperation of each and any remote communication partner in the very same way, for the reverse path. And have the cooperation from both to troubleshoot and solve problems found. 6RD requires only the ISP who has to bridge a v4-only capable access network and troubleshoot any problems arising from the use of 6RD within their only bailiwick. > 1. ISPs that want to impose CGNs on their customers before providing > them any way to use v6 at all. Replace "want to" by "need to". Any fast growing residential ISP is forced to use LSN ("carrier grade" is marketing b.s. term not having any good place in "engineering" circles) as there are no more addresses to support the "one IP per customer connection" model. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From dr@cluenet.de Mon Feb 7 23:47:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D5B3A6BDB for ; Mon, 7 Feb 2011 23:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgtUy+I6g5Rv for ; Mon, 7 Feb 2011 23:47:05 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 2370D3A6CAF for ; Mon, 7 Feb 2011 23:47:05 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id E39A010810F; Tue, 8 Feb 2011 08:47:10 +0100 (CET) Date: Tue, 8 Feb 2011 08:47:10 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110208074710.GB18776@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, Matt Crawford References: <20110203224351.GA27225@srv03.cluenet.de> <201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com> <20110207211826.GB13323@srv03.cluenet.de> <4ABF4068-018A-4D24-93A7-B1069AC99333@fnal.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ABF4068-018A-4D24-93A7-B1069AC99333@fnal.gov> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 07:47:06 -0000 Hi Matt, first of all, thanks for chiming in. On Mon, Feb 07, 2011 at 03:53:29PM -0600, Matt Crawford wrote: > Reaching back almost six years, there was a relevant discussion on > this question. I think the same text answers here ... Well, the only thing that conversation clarifies is the intention to not raise the MTU via RAs. What isn't explained is the reason why this is considered an absolute no-go. If a router (emitting RAs) says that a link is running at MTU 2345, then there's no point in allowing endpoints to run with MTU 1500 as PMTUD will be broken anyway (the router will use MTU 2345 on his interface towards the Ethernet, so won't see a reason to return ICMP packet too big to any IP packet >1500). So in fact, to my understand, either a) RAs shouldn't be allowed to carry MTU >1500 on Ethernet or b) endpoints MUST accept RA MTU >1500 and either be capable of participating in a MTU>1500 LAN or consider the link inoperational. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From ichiroumakino@gmail.com Tue Feb 8 01:14:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701D33A707E for ; Tue, 8 Feb 2011 01:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2RR5EKftAtN for ; Tue, 8 Feb 2011 01:14:40 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 397513A6CDA for ; Tue, 8 Feb 2011 01:14:40 -0800 (PST) Received: by ewy8 with SMTP id 8so3099722ewy.31 for ; Tue, 08 Feb 2011 01:14:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=DHmNjyF8G7ofET5FuXKziONrsh6toJ9bZ8RPRG/eWfY=; b=nnlqoOqLUMZ6dMqPjjdOPNG8b+1Ns1CPHQD1VEFYoxf+gKXN0LGkAMzwxbM7/qtiZg dApRs7G8lI6YsxS67mFI5o2VrWmw7U/teWg1bfx8rmRuoynmOaPBbxFJHq6xbMAzmvay zKHWHIGHXXvROtitdbHvQG8HwbYhsxIrOXgpM= 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=h1a2mtLbpFtNRI+Vl3grxni8Oaziw1j56Lo//ZCYufOYiYer3ZyiCkfQcJXDP30i3c vymNkq+jLBMd4BCsl3l38cvUqddeAccTRZH3x44gM2R588PSU8E84sx/+/4CtDqfwaEC 5hs117qARdIa9wCh2za3Ph8X7VKDlX/FZXE9I= Received: by 10.213.105.80 with SMTP id s16mr4118078ebo.18.1297156485997; Tue, 08 Feb 2011 01:14:45 -0800 (PST) Received: from dhcp-10-61-103-175.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id b52sm3839533eei.19.2011.02.08.01.14.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Feb 2011 01:14:44 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4D50626A.8020801@gmail.com> Date: Tue, 8 Feb 2011 10:14:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 09:14:41 -0000 Brian, >>> I just posted the following draft suggesting that we move the 6to4 = documents to historic. >>=20 >> I think 3056 is harmless enough as it is, provided connectivity to >> "non-6to4" IPv6 is not happening (not *at all*, since you can't = control >> the return path even if the outgoig relay is sane). >>=20 >> 3068 is where the breakage comes from. >>=20 >> 3056 with "only used for packets going to 2002: addresses, sourced = from >> 2002: addresses" is useful. >=20 > Yes, and this why (when someone first proposed solving this problem > by telling people to STOP DOING THAT when they don't even know they're > doing it) I started work on the = draft-carpenter-v6ops-6to4-teredo-advisory > draft. I strongly believe that's a much better use of IETF time and > money than reclassifying RFC 3068 to Historic. And there is no reason > to reclassify RFC 3056, because it isn't the one causing problems. >=20 > So, this draft is > (a) technically wrong, because it reclassifies RFC 3056, and the one = that > does harm is RFC 3068; 6to4 model 1 is not (and has never been) deployed (basically recreates = the 6bone). 6to4 model 2, even with a consenting forward relay suffers the same = issues on the reverse path. in my view 6to4 is not salvageable.=20 > (b) wrong process-wise (RFC 2026 section 4.2.4), because it hasn't = been > superseded and is in widespread use so cannot be called obsolete; from the same paragraph: "or is for any other reason considered to be = obsolete is assigned to the "Historic" level." I think we can equate deprecating 6to4 to deprecating NAT-PT. it is = harmful to IPv6 deployment. > (c) not constructive, because it doesn't offer solutions; the draft requests 6to4 to be deprecated, it is not the place to offer = solutions. I think the "problem" 6to4 solves is miniscule. it provides a mechanism = for us techies to play with IPv6. the solution is that the end user's service provider enables IPv6. = Internet wide tunneling technologies specifically designed to bypass the = underlaying infrastructure are hard to make work. I can't think of a = single example where we have technology that makes that work well, = supporting all the requirements that Fred listed. > (d) distracting us from useful work. 6to4 is what is distracting us. having to fix brokenness triggered by = 6to4. > Note that I am *not* trying to unnaturally prolong the life of 6to4 or > Anycast 6to4. A good way to get rid of them is for all ISPs to deploy = IPv6, > for example. and until that happens (SP deploys IPv6), IPv6 deployment will not = happen. 6to4 does not in any way accelerate IPv6 deployment. if the draft can achieve that: - CPE and hosts vendors stop enabling 6to4 by default - no-one advertises 6to4 AAAA records in DNS - 6to4 is put at the absolute bottom (with Teredo) in the SAS/DAS = algorithms. - people stop considering 6to4 as a valid transitioning mechanism; = there are too many choices already. cheers, Ole= From remi.despres@free.fr Tue Feb 8 01:30:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78BB13A6CC4 for ; Tue, 8 Feb 2011 01:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.527 X-Spam-Level: X-Spam-Status: No, score=-1.527 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thgjTegB8uBK for ; Tue, 8 Feb 2011 01:30:27 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by core3.amsl.com (Postfix) with ESMTP id 720EC3A6CF5 for ; Tue, 8 Feb 2011 01:30:27 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2408.sfr.fr (SMTP Server) with ESMTP id 9451E7000090; Tue, 8 Feb 2011 10:30:33 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2408.sfr.fr (SMTP Server) with ESMTP id CB5BE700008D; Tue, 8 Feb 2011 10:30:32 +0100 (CET) X-SFR-UUID: 20110208093032833.CB5BE700008D@msfrf2408.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D506418.9090706@gmail.com> Date: Tue, 8 Feb 2011 10:30:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5093C4FE-7D47-4E9A-AE61-73C1423C470D@free.fr> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505F79.907@brightok.net> <4D506418.9090706@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] AAAA records [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 09:30:28 -0000 Le 7 f=E9vr. 2011 =E0 22:28, Brian E Carpenter a =E9crit : >=20 > (I'm breaking Jack's message down into separate topics with > appropriate subject headers) >=20 >=20 > On 2011-02-08 10:09, Jack Bates wrote: > ... >>=20 >> 1) If 6to4 Addressing is advertised via AAAA records, publishers = should >> be aware that CGN/LSN/Provider NAT will break customers behind them = from >> utilizing direct 6to4 communications >=20 > Yes, this is a good point. Should we simply recommend against = advertising > *any* 6to4 address in DNS, or at least provide a very strong health = warning? After this discussion, there remains one scenario worth documenting if a = warning against 6to4 AAAAs is envisaged. In this scenario 6to4 AAAAs add connectivity without destroying any: - There are servers in a site that has a public IPv4 address and no = native-IPv6 prefix (like most residential sites today), and whose CPE = supports 6to4. - These servers have neither As nor a native-IPv6 AAAAs to publish. = They have 6to4 AAAAs as only reachable addresses - If they publish these 6to4 AAAAs, they becomes accessible by clients = that have real 6to4 connectivity (i.e. not prevented by any firewall), = and by native-IPv6-address clients that have upstream access to a 6to4 = relay.=20 - Other clients having no chance to reach these servers anyway, nothing = is broken. Regards, RD From ichiroumakino@gmail.com Tue Feb 8 01:48:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A4A3A7096 for ; Tue, 8 Feb 2011 01:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1Ytq1yNsKBz for ; Tue, 8 Feb 2011 01:48:23 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 5D05D3A7095 for ; Tue, 8 Feb 2011 01:48:23 -0800 (PST) Received: by eyd10 with SMTP id 10so3098812eyd.31 for ; Tue, 08 Feb 2011 01:48:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=AsANj3wOMDYbJi+5GUykcURGZnuqcHSktcBAKNsPgAQ=; b=cBGdbeCZq6VggZW85tPnQ1vxaGj0MKrVsn+DRcNYgmY1IVKQndur+9nP8bGlvQounp 3+e3kFST6cnRSAkGs8mBb1SizYpNcU+Kw+dlMjrQ9ptwbXBeJA1oJVTW5QB1/dTTpXnH hgu03BkelXOElLcYSUS++GA/1MdJX278n5/iE= 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=wkqdI73yu1TfzqB613Y774ozxOY0bNu8wJm5ClzUDabf0jjex+dRkoNjlcJkgcIh84 G4t4l1yeS/JOraXtgQ6ZwiOUYlRm/XkNAYbmjR2Gfwrsk5bGbAe1WZ4Wj7ztZ1d2IT9L nbYAvxUwWcIedUrfjGYhBlrL2HLnkO+68Lqmg= Received: by 10.14.47.193 with SMTP id t41mr1398930eeb.21.1297158509141; Tue, 08 Feb 2011 01:48:29 -0800 (PST) Received: from ams3-vpn-dhcp6219.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id t5sm3865604eeh.2.2011.02.08.01.48.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Feb 2011 01:48:28 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> Date: Tue, 8 Feb 2011 10:48:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3CC4ED70-B57F-49EA-8ECF-7827E1D9E6A2@employees.org> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 09:48:24 -0000 Keith, >> * Ole Troan >>=20 >>> I just posted the following draft suggesting that we move the 6to4 >>> documents to historic. >>=20 >> Ole, >>=20 >> I agree fully. Thank you for writing the draft. >=20 > I strongly disagree. You're trying to kill the most widely deployed = v6 transition mechanism that we have, without there being anything like = a suitable replacement. >=20 > The fix for 6to4's problems is proper network configuration. proper network configuration of every network on the planet? I just can't see how 'sane' 6to4 can be deployed... - no blocking of protocol 41 anywhere - no bogons, no CGNs - no MTU issues, no blocking of ICMPv4 or ICMPv6. all IPv4 routers = upgraded to provide full packet in ICMPv4 - all IPv6 content providers have a 6to4 address available - every IPv4 only network run a forward relay - every IPv6 network run a reverse relay cheers, Ole= From ek@google.com Tue Feb 8 01:49:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D44D53A709F for ; Tue, 8 Feb 2011 01:49:17 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVqtqH4G3OkV for ; Tue, 8 Feb 2011 01:49:17 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8B8203A709A for ; Tue, 8 Feb 2011 01:49:16 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p189nM7Q020626 for ; Tue, 8 Feb 2011 01:49:22 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297158562; bh=OBNq8QEuQhQJB2WMN4zAGvv6uNw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=VUEnpyjlPSzdoh0+/vXroHoUtYRfMCRw+gaIbiP0f+FKUndWsLVO/Yyy2JYLGEwv8 hErUO26FEQkPFNiWY0ptg== Received: from qwk4 (qwk4.prod.google.com [10.241.195.132]) by wpaz13.hot.corp.google.com with ESMTP id p189mlLP004448 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 8 Feb 2011 01:49:21 -0800 Received: by qwk4 with SMTP id 4so4161365qwk.4 for ; Tue, 08 Feb 2011 01:49:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6euWkI53OgQutxo/Fw0lw8NH0wTxZ+DWTF+467sAzWE=; b=q0grBrgzL5PvForN0JxnooblFax/vt0BsRdv3aDHkCXwow95v85C5p4M5xwv7pfY1R mCKkhIeootgrBpc/ztvQ== 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=U6UdfHNXD/yuz3vlMJDJsXrU9Dxq31edm725HjSU9zoYmRmj7PP8egY8hs6YE53LPb JZr2ojywNpkCF/dEQo6Q== MIME-Version: 1.0 Received: by 10.229.213.80 with SMTP id gv16mr11814893qcb.181.1297158560594; Tue, 08 Feb 2011 01:49:20 -0800 (PST) Received: by 10.229.111.210 with HTTP; Tue, 8 Feb 2011 01:49:20 -0800 (PST) In-Reply-To: <4D506418.9090706@gmail.com> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505F79.907@brightok.net> <4D506418.9090706@gmail.com> Date: Tue, 8 Feb 2011 09:49:20 +0000 Message-ID: From: Erik Kline To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] AAAA records [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 09:49:17 -0000 On 7 February 2011 21:28, Brian E Carpenter wrote: > > (I'm breaking Jack's message down into separate topics with > appropriate subject headers) > > > On 2011-02-08 10:09, Jack Bates wrote: > ... >> >> 1) If 6to4 Addressing is advertised via AAAA records, publishers should >> be aware that CGN/LSN/Provider NAT will break customers behind them from >> utilizing direct 6to4 communications > > Yes, this is a good point. Should we simply recommend against advertising > *any* 6to4 address in DNS, or at least provide a very strong health warning? I already added code to our authoritative DNS server to never, ever* serve an AAAA to a resolver asking for same via 6to4 or Teredo. I should double-check that the restriction still applies to requests with such client IP information inside the draft EDNS Client Subnet option, but IIRC it does. -Erik * there's separate code for "always serving AAAAs" for experimental measurement purposes and things like ipv6.google.com From remi.despres@free.fr Tue Feb 8 02:09:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECDC23A6D6A for ; Tue, 8 Feb 2011 02:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.288 X-Spam-Level: X-Spam-Status: No, score=-0.288 tagged_above=-999 required=5 tests=[AWL=-0.939, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9-eq+0ItSPD for ; Tue, 8 Feb 2011 02:09:23 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by core3.amsl.com (Postfix) with ESMTP id 2CE253A6D69 for ; Tue, 8 Feb 2011 02:09:23 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 02E3F7000098; Tue, 8 Feb 2011 11:09:29 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id CEE397000091; Tue, 8 Feb 2011 11:09:28 +0100 (CET) X-SFR-UUID: 20110208100928847.CEE397000091@msfrf2403.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 8 Feb 2011 11:09:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Fred Baker X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 10:09:24 -0000 Le 8 f=E9vr. 2011 =E0 04:50, Fred Baker a =E9crit : > Question for the assembled throng: We have been having an active = discussion for the past coupe of weeks on Happy Eyeballs. > What do people want to see happen in = draft-wing-v6ops-happy-eyeballs-ipv6? IMHO, this document makes a lot of sense, and its becoming an RFC asap = is most useful. Yet, I wonder whether it should better be informational than standards = track. The reason is that it only concerns implementation in hosts, and that = many variants are possible. Describing what the proposed technique solves is IMHO both important and = sufficient. OS vendors will continue to decide what to do, without any particular = variant being considered the standard. Regards, RD From remi.despres@free.fr Tue Feb 8 02:27:54 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 863AC3A70D6 for ; Tue, 8 Feb 2011 02:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.726 X-Spam-Level: X-Spam-Status: No, score=-0.726 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_05=-1.11, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dgkCyCOZ9Mj for ; Tue, 8 Feb 2011 02:27:53 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by core3.amsl.com (Postfix) with ESMTP id 879B63A70D0 for ; Tue, 8 Feb 2011 02:27:53 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id C336B700008E; Tue, 8 Feb 2011 11:27:59 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id EEED0700008C; Tue, 8 Feb 2011 11:27:58 +0100 (CET) X-SFR-UUID: 20110208102758978.EEED0700008C@msfrf2416.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> Date: Tue, 8 Feb 2011 11:27:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 10:27:54 -0000 Le 7 f=E9vr. 2011 =E0 20:11, Fred Baker a =E9crit : > ... > If I can summarize Keith's concern with 6rd, it is not that it doesn't = deploy an IPv6-capable service; it is that > the service has a smaller Path MTU than the native MTU of links he = uses, A negligible concern compared to the lack of deployed native-IPv6 = addresses, and to the complexity of problems that have to be faced with = 6to4. As long as PMTUD isn't considered reliable, site-to-site IPv6 is safer = with MTU =3D 1280 than with any other choice. > often has a broken PMTU implementation due to ICMPv6 filtering AFAIK, broken PMTUD isn't due to 6rd, but more data on this subject are = welcome. Anyway, that's the reason to stay with 1280 (still permitting = application-layer datagrams to be much larger). > , and is not native. Not natively routed in the ISP network, that's true. But:: - Hosts can't even notice it - Addresses are as native as those natively routed by ISPs. > If I can summarize the views of those using it (such as a Dutch = provider I spoke with Wednesday in London), it's not that they don't = want or expect to deploy a native IPv6 service, it's that they want to = deploy an IPv6 service now and have infrastructure that they can't = immediately upgrade (such as, in the Dutch case I mentioned, a service = network that they have to use that is IPv4-only for the foreseeable = future). That's exactly the scope of 6rd, and why it is useful. Regards, RD From martin@millnert.se Tue Feb 8 02:59:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DB713A7107 for ; Tue, 8 Feb 2011 02:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QplsolPa68N for ; Tue, 8 Feb 2011 02:59:11 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by core3.amsl.com (Postfix) with ESMTP id 63A8D3A7109 for ; Tue, 8 Feb 2011 02:59:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 4A0F27787; Tue, 8 Feb 2011 12:04:06 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2vwolhosD2W; Tue, 8 Feb 2011 12:04:06 +0100 (CET) Received: from [IPv6:2a02:9a0:100:2400::6] (shakira.us.millnert.se [IPv6:2a02:9a0:100:2400::6]) by ncis.csbnet.se (Postfix) with ESMTPSA id CC0D1774B; Tue, 8 Feb 2011 12:04:04 +0100 (CET) From: Martin Millnert To: Ole Troan In-Reply-To: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 08 Feb 2011 05:59:11 -0500 Message-ID: <1297162751.4205.42.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 10:59:12 -0000 Ole, On Tue, 2011-02-08 at 10:14 +0100, Ole Troan wrote: > if the draft can achieve that: > - CPE and hosts vendors stop enabling 6to4 by default > - no-one advertises 6to4 AAAA records in DNS > - 6to4 is put at the absolute bottom (with Teredo) in the SAS/DAS > algorithms. > - people stop considering 6to4 as a valid transitioning mechanism; > there are too many choices already. The first (and maybe 3rd) point seems to be the most potent ones to me, because of the relative few orgs who have some form of ability of making this happen on a lot of hosts at the same time. But the important thing to figure out at this point, IMO, is: would they disable it on running hosts? Eg, would host stack vendors flip 6to4 default off on running hosts today (there are a few) given this drafts existence? My support of this draft must follow the answer to that question. (I seem to remember DNS to well-known addresses being deprecated but still used by one of the vendors.) Regards, Martin From randy@psg.com Tue Feb 8 04:25:30 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651493A7047 for ; Tue, 8 Feb 2011 04:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIAcTnZPWvNf for ; Tue, 8 Feb 2011 04:25:29 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id D0EE93A6DE4 for ; Tue, 8 Feb 2011 04:25:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pmmcl-000MAX-CL; Tue, 08 Feb 2011 12:24:51 +0000 Date: Tue, 08 Feb 2011 04:24:50 -0800 Message-ID: From: Randy Bush To: Jack Bates In-Reply-To: <4D508ADD.8060601@brightok.net> References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <20110208070348.2fedcfea@opy.nosense.org> <4D508ADD.8060601@brightok.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 12:25:30 -0000 > We established a HE tunnel specifically to handle a 6to4 relay years > ago. satan has a tail and horns From moore@network-heretics.com Tue Feb 8 05:07:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD3D63A7048 for ; Tue, 8 Feb 2011 05:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuUL930jWBxv for ; Tue, 8 Feb 2011 05:07:21 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id D97093A6DDC for ; Tue, 8 Feb 2011 05:07:20 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmnHx-0007at-Uy; Tue, 08 Feb 2011 08:07:26 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <3CC4ED70-B57F-49EA-8ECF-7827E1D9E6A2@employees.org> Date: Tue, 8 Feb 2011 08:07:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <3CC4ED70-B57F-49EA-8ECF-7827E1D9E6A2@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940527ce3f804c1bdd61d480efb4a9748f0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 13:07:21 -0000 On Feb 8, 2011, at 4:48 AM, Ole Troan wrote: > Keith, >=20 >>> * Ole Troan >>>=20 >>>> I just posted the following draft suggesting that we move the 6to4 >>>> documents to historic. >>>=20 >>> Ole, >>>=20 >>> I agree fully. Thank you for writing the draft. >>=20 >> I strongly disagree. You're trying to kill the most widely deployed = v6 transition mechanism that we have, without there being anything like = a suitable replacement. >>=20 >> The fix for 6to4's problems is proper network configuration. >=20 > proper network configuration of every network on the planet? > I just can't see how 'sane' 6to4 can be deployed... > - no blocking of protocol 41 anywhere what's wrong with that? you act like it's somehow bizarre to expect IP = packets to get through the network unchanged.=20 > - no bogons, no CGNs admit it, bogons and CGNs are pretty broken. maybe they're unavoidable = given the lack of v4 space. but what I'm saying is not to get rid of = them, I'm saying those guys need to offer native v6 on the same ports = ASAP. > - no MTU issues, no blocking of ICMPv4 or ICMPv6. all IPv4 routers = upgraded to provide full packet in ICMPv4 YMMV, but I found MTU clamping to work pretty well for me.=20 yeah, general blocking of ICMP is pretty brain damaged. though = carefully chosen blocking can work. > - all IPv6 content providers have a 6to4 address available not necessary. > - every IPv4 only network run a forward relay > - every IPv6 network run a reverse relay nor these. why is it unreasonable to expect network operators to move packets = across the net intact? isn't that their job? Keith From moore@network-heretics.com Tue Feb 8 05:30:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE0563A714A for ; Tue, 8 Feb 2011 05:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPzdby1mhLko for ; Tue, 8 Feb 2011 05:30:07 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 3ECEE3A7149 for ; Tue, 8 Feb 2011 05:30:07 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Pmne0-0003aP-9n; Tue, 08 Feb 2011 08:30:13 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Tue, 8 Feb 2011 08:30:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> To: Ole Troan X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940b005461a0113ea1c101837f6d77b0bd7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 13:30:09 -0000 On Feb 8, 2011, at 4:14 AM, Ole Troan wrote: > Brian, >=20 >>>> I just posted the following draft suggesting that we move the 6to4 = documents to historic. >>>=20 >>> I think 3056 is harmless enough as it is, provided connectivity to >>> "non-6to4" IPv6 is not happening (not *at all*, since you can't = control >>> the return path even if the outgoig relay is sane). >>>=20 >>> 3068 is where the breakage comes from. >>>=20 >>> 3056 with "only used for packets going to 2002: addresses, sourced = from >>> 2002: addresses" is useful. >>=20 >> Yes, and this why (when someone first proposed solving this problem >> by telling people to STOP DOING THAT when they don't even know = they're >> doing it) I started work on the = draft-carpenter-v6ops-6to4-teredo-advisory >> draft. I strongly believe that's a much better use of IETF time and >> money than reclassifying RFC 3068 to Historic. And there is no reason >> to reclassify RFC 3056, because it isn't the one causing problems. >>=20 >> So, this draft is >> (a) technically wrong, because it reclassifies RFC 3056, and the one = that >> does harm is RFC 3068; >=20 > 6to4 model 1 is not (and has never been) deployed (basically recreates = the 6bone). Incorrect on both counts. > 6to4 model 2, even with a consenting forward relay suffers the same = issues on the reverse path. > in my view 6to4 is not salvageable.=20 Perhaps that's because you haven't tried to identify solutions? it is = possible, for instance, to identify and marginalize broken relay = routers. >> (b) wrong process-wise (RFC 2026 section 4.2.4), because it hasn't = been >> superseded and is in widespread use so cannot be called obsolete; >=20 > from the same paragraph: "or is for any other reason considered to be = obsolete is > assigned to the "Historic" level." >=20 > I think we can equate deprecating 6to4 to deprecating NAT-PT. it is = harmful to IPv6 deployment. 6to4 is not harmful to IPv6 deployment. ISPs that break IPv4 are = harmful to IPv6 deployment. >> (c) not constructive, because it doesn't offer solutions; >=20 > the draft requests 6to4 to be deprecated, it is not the place to offer = solutions. > I think the "problem" 6to4 solves is miniscule. it provides a = mechanism for us techies to play with IPv6. 6to4 provides a way for anyone with any properly working IPv4 connect to = connect to any IPv6 host. That's a huge win. It eliminates one of the = barriers toward IPv6 acceptance by providing a means for universal = access to IPv6 over any properly working IPv4 connection. > the solution is that the end user's service provider enables IPv6. = Internet wide tunneling technologies specifically designed to bypass the = underlaying infrastructure are hard to make work. I can't think of a = single example where we have technology that makes that work well, = supporting all the requirements that Fred listed. >=20 >> (d) distracting us from useful work. >=20 > 6to4 is what is distracting us. having to fix brokenness triggered by = 6to4. No, 6to4 is not broken. 6to4 is just sending IP packets and expecting = them to get to the hosts associated with their destination addresses = intact. The network is broken because of many brain damaged practices in place = for other reasons, and 6to4 is one of many things suffering because of = it. =20 (I sometimes suspect that 6to4 is also suffering because some operators = see it as an end-run around them, so they don't mind implementing = measures that penalize it. But that's not a problem with 6to4....) >> Note that I am *not* trying to unnaturally prolong the life of 6to4 = or >> Anycast 6to4. A good way to get rid of them is for all ISPs to deploy = IPv6, >> for example. >=20 > and until that happens (SP deploys IPv6), IPv6 deployment will not = happen. 6to4 does not in any way accelerate IPv6 deployment. Completely incorrect. See above. I think the statement in a nutshell is this: as long as operators insist = on seeing 6to4 as a 'problem' rather than a way to provide their = customers good service and a useful transition tool, they're going to = keep sabotaging it. By doing so they're actually impairing deployment = of IPv6. Keith From moore@network-heretics.com Tue Feb 8 05:40:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531E03A714C for ; Tue, 8 Feb 2011 05:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tNI2XD-ySVI for ; Tue, 8 Feb 2011 05:40:22 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 62B683A7148 for ; Tue, 8 Feb 2011 05:40:22 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Pmnnw-0006n7-Dl; Tue, 08 Feb 2011 08:40:29 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110208073126.GA18776@srv03.cluenet.de> Date: Tue, 8 Feb 2011 08:40:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1C37F0A2-88C6-4CB3-B624-608E0B7364F1@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <20110208073126.GA18776@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940a407d2997899ca23eec77e94d8e33a66350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 13:40:23 -0000 On Feb 8, 2011, at 2:31 AM, Daniel Roesen wrote: > On Tue, Feb 08, 2011 at 12:44:41AM -0500, Keith Moore wrote: >> My problem with 6rd is that it's not something than an individual >> user who needs IPv6 can deploy independently of support from his ISP. >> 6to4 is such a mechanism, and that's it's great virtue. =20 >=20 > That's an illusion. In contrast to 6RD, anycast 6to4 requires the > cooperation of both the ISP of the individual user (either to operate = a > reliable and capacity-wise sufficiently scaled 6to4 relay or make sure > there is one reachable for his customers, as well as the cooperation = of > each and any remote communication partner in the very same way, for = the > reverse path. And have the cooperation from both to troubleshoot and > solve problems found. I get what I think is your point, which is that in order for 6to4 to = work, operators actually have to make sure that their IP networks work = properly (deliver packets intact to their specified destinations), and = they either have to=20 a) operate their own properly working anycast relays, or=20 b) do some QA on any advertisements of anycast relays that they receive = from peers and filter out those that don't work well, or c) just get lucky at having peers with working anycast relays ...but I've also successfully used 6to4 on/through many networks that = didn't have any explicit operator support for it. =20 Also, I don't think that any of the above should be onerous. e.g. = regarding route advertisements, don't operators have to do some amount = of QA and filtering for route advertisements anyway? Can operators = really get away with blindly trusting their peers to advertise = reasonable BGP routes in general? > 6RD requires only the ISP who has to bridge a v4-only capable access > network and troubleshoot any problems arising from the use of 6RD = within > their only bailiwick. If operators prefer either 6rd or pure v6 to 6to4, I have no problem = with that. Just don't break 6to4 before implementing something better. >> 1. ISPs that want to impose CGNs on their customers before providing >> them any way to use v6 at all. >=20 > Replace "want to" by "need to". I don't really buy "need to". There are lots of ways to better allocate = existing IPv4 addresses that are probably applicable to most networks. = What I accept is that CGN is the current fad. Keith From jbates@brightok.net Tue Feb 8 05:51:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB6A3A6924 for ; Tue, 8 Feb 2011 05:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwzYYPvzt8EZ for ; Tue, 8 Feb 2011 05:51:31 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 2E1D83A6DD4 for ; Tue, 8 Feb 2011 05:51:27 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18DpU4w016643; Tue, 8 Feb 2011 07:51:30 -0600 (CST) Message-ID: <4D514A5E.5000404@brightok.net> Date: Tue, 08 Feb 2011 07:51:26 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> In-Reply-To: <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 13:51:32 -0000 On 2/7/2011 11:23 PM, Keith Moore wrote: > there's a very real risk that CGN will thwart the ability to transition to IPv6. it may need a mercy killing. > Errr, not at all. You try doing all the things users want to do with CGN. No ISP wants to do it. Jack From jbates@brightok.net Tue Feb 8 05:56:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45AEE3A6DD1 for ; Tue, 8 Feb 2011 05:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDrDyQTseZQc for ; Tue, 8 Feb 2011 05:56:28 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id B46443A68C0 for ; Tue, 8 Feb 2011 05:56:28 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18DuX0B017713; Tue, 8 Feb 2011 07:56:33 -0600 (CST) Message-ID: <4D514B8E.6030703@brightok.net> Date: Tue, 08 Feb 2011 07:56:30 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Roesen , v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 13:56:31 -0000 On 2/8/2011 12:38 AM, Keith Moore wrote: > Sure, some ISPs and content providers don't like it, but there's no transition scheme that everybody likes. > And deliberate denial of service attacks on 6to4 are completely out of line. I think both of you missed Cameron's point. His IPv4 is CGN, so 6to4 breaks. The only way he could revive any 6to4 functionality would be NPTv6 on 6to4 relay, which he prefers to just offer the IPv6 native trial over doing that. Jack From moore@network-heretics.com Tue Feb 8 05:59:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32513A6DDF for ; Tue, 8 Feb 2011 05:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RHIkkJ6WKHr for ; Tue, 8 Feb 2011 05:59:40 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id EAD0B3A6DD1 for ; Tue, 8 Feb 2011 05:59:39 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Pmo6b-00075Z-Gr; Tue, 08 Feb 2011 08:59:45 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D514A5E.5000404@brightok.net> Date: Tue, 8 Feb 2011 08:59:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940851d94bd40dc0162dc6f46e6b66f172d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 13:59:40 -0000 On Feb 8, 2011, at 8:51 AM, Jack Bates wrote: > On 2/7/2011 11:23 PM, Keith Moore wrote: >> there's a very real risk that CGN will thwart the ability to = transition to IPv6. it may need a mercy killing. >>=20 >=20 > Errr, not at all. You try doing all the things users want to do with = CGN. No ISP wants to do it. Well, it seems to me that 6to4 is yet another thing that users want to = do with CGN, and the operator outcry against 6to4 is that somehow the = operators think that people don't want/need a way to do 6to4..or at = least some other form of IPv6 that works without explicit setup on the = user's part. Keith From simon.perreault@viagenie.ca Tue Feb 8 06:02:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035DE3A7157 for ; Tue, 8 Feb 2011 06:02:03 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkCIHZjzC44J for ; Tue, 8 Feb 2011 06:02:01 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 9126A3A7143 for ; Tue, 8 Feb 2011 06:01:25 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c003:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A5F4820D07 for ; Tue, 8 Feb 2011 09:01:31 -0500 (EST) Message-ID: <4D514CBB.7010007@viagenie.ca> Date: Tue, 08 Feb 2011 09:01:31 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:02:03 -0000 On 2011-02-07 23:41, Cameron Byrne wrote: > Is it possible that happy eyeballs is not feasible to implement within > the short time frame that it may be useful? Even in a pure IPv6-only world, happy eyeballs would still be useful. When a name resolves to multiple addresses, trying them in parallel has advantages over trying them in sequence. 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 jbates@brightok.net Tue Feb 8 06:02:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EBA13A6DF1 for ; Tue, 8 Feb 2011 06:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.063 X-Spam-Level: X-Spam-Status: No, score=-3.063 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA88adhM-fig for ; Tue, 8 Feb 2011 06:02:05 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 2A7683A7156 for ; Tue, 8 Feb 2011 06:01:52 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18E1tuc018823; Tue, 8 Feb 2011 08:01:56 -0600 (CST) Message-ID: <4D514CCF.5080900@brightok.net> Date: Tue, 08 Feb 2011 08:01:51 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505F79.907@brightok.net> <4D506418.9090706@gmail.com> <5093C4FE-7D47-4E9A-AE61-73C1423C470D@free.fr> In-Reply-To: <5093C4FE-7D47-4E9A-AE61-73C1423C470D@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] AAAA records [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:02:06 -0000 On 2/8/2011 3:30 AM, Rémi Després wrote: > Le 7 févr. 2011 à 22:28, Brian E Carpenter a écrit : > >> (I'm breaking Jack's message down into separate topics with >> appropriate subject headers) >> >> >> On 2011-02-08 10:09, Jack Bates wrote: >> ... >>> 1) If 6to4 Addressing is advertised via AAAA records, publishers should >>> be aware that CGN/LSN/Provider NAT will break customers behind them from >>> utilizing direct 6to4 communications >> Yes, this is a good point. Should we simply recommend against advertising >> *any* 6to4 address in DNS, or at least provide a very strong health warning? > After this discussion, there remains one scenario worth documenting if a warning against 6to4 AAAAs is envisaged. > I don't think it's necessary. I believe the warning will be CGN specific. It's a good reminder that when your 6to4 breaks, you have something to look for. There's no problem with using AAAA for 6to4. You just won't have a lot of connectivity from a lot of different networks. If not interested in those networks or their users, there is no problem. Jack From moore@network-heretics.com Tue Feb 8 06:04:18 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7593A7143 for ; Tue, 8 Feb 2011 06:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOCyCRC91o6v for ; Tue, 8 Feb 2011 06:04:17 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 274523A7141 for ; Tue, 8 Feb 2011 06:04:17 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmoB2-0004QN-Ej; Tue, 08 Feb 2011 09:04:22 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-36-1039075932 From: Keith Moore In-Reply-To: <4D514B8E.6030703@brightok.net> Date: Tue, 8 Feb 2011 09:04:15 -0500 Message-Id: <8D3FCA0C-30F2-439B-8A4F-3139E43AEF33@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D514B8E.6030703@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940740d64fe367dbfda072cf982a1c76e5c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: Daniel Roesen , v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:04:18 -0000 --Apple-Mail-36-1039075932 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 8, 2011, at 8:56 AM, Jack Bates wrote: > On 2/8/2011 12:38 AM, Keith Moore wrote: >> Sure, some ISPs and content providers don't like it, but there's no = transition scheme that everybody likes. >> And deliberate denial of service attacks on 6to4 are completely out = of line. >=20 > I think both of you missed Cameron's point. His IPv4 is CGN, so 6to4 = breaks. The only way he could revive any 6to4 functionality would be = NPTv6 on 6to4 relay, which he prefers to just offer the IPv6 native = trial over doing that. I think that's fine... the main thing is that a host connecting via CGN = should also see v6 RAs on the same link, so it will automagically enable = v6 that way and won't need to enable 6to4. =20 Though I do think there's a huge problem with CGNs reusing space that is = not already known to be private space... host OSes have no indication = that they should not enable 6to4 on those stacks. =20 (Blocking port 41 is a poor solution; returning ICMP unreachable is not = much better...do you really want to break ALL IP-in-IP tunnels?) --Apple-Mail-36-1039075932 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = 2/8/2011 12:38 AM, Keith Moore wrote:
Sure, = some ISPs and content providers don't like it, but there's no transition = scheme that everybody likes.
And= deliberate denial of service attacks on 6to4 are completely out of = line.

I think both of you missed Cameron's point. = His IPv4 is CGN, so 6to4 breaks. The only way he could revive any 6to4 = functionality would be NPTv6 on 6to4 relay, which he prefers to just = offer the IPv6 native trial over doing that.

I = think that's fine... the main thing is that a host connecting via CGN = should also see v6 RAs on the same link, so it will automagically enable = v6 that way and won't need to enable 6to4. =  

Though I do think there's a huge problem = with CGNs reusing space that is not already known to be private space... = host OSes have no indication that they should not enable 6to4 on those = stacks.  
(Blocking port 41 is a poor solution; returning = ICMP unreachable is not much better...do you really want to break ALL = IP-in-IP tunnels?)


= --Apple-Mail-36-1039075932-- From jbates@brightok.net Tue Feb 8 06:05:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7934D3A7134 for ; Tue, 8 Feb 2011 06:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk6cGD-N7avx for ; Tue, 8 Feb 2011 06:05:27 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 5A0723A6DF7 for ; Tue, 8 Feb 2011 06:05:24 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18E5NTj019676; Tue, 8 Feb 2011 08:05:23 -0600 (CST) Message-ID: <4D514D9F.6060703@brightok.net> Date: Tue, 08 Feb 2011 08:05:19 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Randy Bush References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <20110208070348.2fedcfea@opy.nosense.org> <4D508ADD.8060601@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:05:28 -0000 On 2/8/2011 6:24 AM, Randy Bush wrote: >> We established a HE tunnel specifically to handle a 6to4 relay years >> ago. > satan has a tail and horns You crack me up, Randy. Had to maintain QOS until I could roll out native IPv6. I don't like the tunnel for mass production traffic, so I've had to wait on native connectivity. I just recently managed to get the L3 native v6 circuit. Better than nothing, I guess. Jack From jbates@brightok.net Tue Feb 8 06:07:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E693A3A6E03 for ; Tue, 8 Feb 2011 06:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBLLnMYLVUmJ for ; Tue, 8 Feb 2011 06:07:24 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 3045D3A6D8F for ; Tue, 8 Feb 2011 06:07:24 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18E7T2X020279; Tue, 8 Feb 2011 08:07:29 -0600 (CST) Message-ID: <4D514E1D.4040000@brightok.net> Date: Tue, 08 Feb 2011 08:07:25 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D514B8E.6030703@brightok.net> <8D3FCA0C-30F2-439B-8A4F-3139E43AEF33@network-heretics.com> In-Reply-To: <8D3FCA0C-30F2-439B-8A4F-3139E43AEF33@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Roesen , v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:07:25 -0000 On 2/8/2011 8:04 AM, Keith Moore wrote: > I think that's fine... the main thing is that a host connecting via > CGN should also see v6 RAs on the same link, so it will automagically > enable v6 that way and won't need to enable 6to4. > > Though I do think there's a huge problem with CGNs reusing space that > is not already known to be private space... host OSes have no > indication that they should not enable 6to4 on those stacks. > (Blocking port 41 is a poor solution; returning ICMP unreachable is > not much better...do you really want to break ALL IP-in-IP tunnels?) > Doesn't happen, though. You have to sign up for IPv6 from them. Otherwise, it's still a v4 world; for now. Jack From jbates@brightok.net Tue Feb 8 06:09:46 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C301B3A7011 for ; Tue, 8 Feb 2011 06:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.213 X-Spam-Level: X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eORy8JQyfQd1 for ; Tue, 8 Feb 2011 06:09:46 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 026F53A6E16 for ; Tue, 8 Feb 2011 06:09:45 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18E9p48020909; Tue, 8 Feb 2011 08:09:51 -0600 (CST) Message-ID: <4D514EAB.3070109@brightok.net> Date: Tue, 08 Feb 2011 08:09:47 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> In-Reply-To: <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:09:46 -0000 On 2/8/2011 7:59 AM, Keith Moore wrote: > Well, it seems to me that 6to4 is yet another thing that users want to do with CGN, and the operator outcry against 6to4 is that somehow the operators think that people don't want/need a way to do 6to4..or at least some other form of IPv6 that works without explicit setup on the user's part. Hey, I even gave one idea for a semi broken 6to4 anycast mechanism behind CGN. Sorry, but CGN breaks things. That's the way it will be. If native IPv6 isn't to every location, they'll be behind the broken net. FYI, CGN is the best thing for IPv6. It's an IPv4 killer app. :) Jack From moore@network-heretics.com Tue Feb 8 06:11:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843883A6DED for ; Tue, 8 Feb 2011 06:11:26 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWvHVeb1RHev for ; Tue, 8 Feb 2011 06:11:19 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 041D33A714C for ; Tue, 8 Feb 2011 06:11:19 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmoHs-0003Ow-D7; Tue, 08 Feb 2011 09:11:24 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D514EAB.3070109@brightok.net> Date: Tue, 8 Feb 2011 09:11:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0BDAB499-AAE2-432B-B7C7-C2F03744FC93@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <4D514EAB.3070109@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940e5eda74ee0019e845d19ebdaf79a7486350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:11:28 -0000 On Feb 8, 2011, at 9:09 AM, Jack Bates wrote: > On 2/8/2011 7:59 AM, Keith Moore wrote: >> Well, it seems to me that 6to4 is yet another thing that users want = to do with CGN, and the operator outcry against 6to4 is that somehow the = operators think that people don't want/need a way to do 6to4..or at = least some other form of IPv6 that works without explicit setup on the = user's part. >=20 > Hey, I even gave one idea for a semi broken 6to4 anycast mechanism = behind CGN. Sorry, but CGN breaks things. That's the way it will be. If = native IPv6 isn't to every location, they'll be behind the broken net. >=20 > FYI, CGN is the best thing for IPv6. It's an IPv4 killer app. :) unfortunately, it might end up killing v6 also. From ek@google.com Tue Feb 8 06:11:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D62AA3A7153 for ; Tue, 8 Feb 2011 06:11:36 -0800 (PST) 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=[AWL=-0.001, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSD8VcxCKjlw for ; Tue, 8 Feb 2011 06:11:35 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 08E743A7151 for ; Tue, 8 Feb 2011 06:11:34 -0800 (PST) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p18EBfMx020448 for ; Tue, 8 Feb 2011 06:11:41 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297174301; bh=ImR52QOCA6WSDcJP77A6vlnXYVE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=SdQZtL3N3KKb6/hCVE9MXFSkWYAApbLnKmYtyRwNuS+wWIQiPwKRR4tO6lh6G5Jfd 91WjnsG9bFOdJr6ycKOWg== Received: from qwe5 (qwe5.prod.google.com [10.241.194.5]) by kpbe16.cbf.corp.google.com with ESMTP id p18EBe4D019562 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 8 Feb 2011 06:11:40 -0800 Received: by qwe5 with SMTP id 5so5321802qwe.40 for ; Tue, 08 Feb 2011 06:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6qtjQmbG0clnkAfFMbTg2X3X+uOmuZG0rwqO9tC2e+k=; b=rHta3YqXLZA8j+6AggioKD6aV4QEOlyojSOTsIMIDKai1ehnCr8by969OT+6nQanp9 grJT90XnmJEdmO67piZQ== 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=Bbe22HQCO6Ss2bEEXr+ZevlyqTgDojy88KdOxDrflLhL1yDQeAbEnIL/7WSZcjDNAz pn3o1KUigT5gsH7eCQgg== MIME-Version: 1.0 Received: by 10.229.82.14 with SMTP id z14mr11974013qck.257.1297174299934; Tue, 08 Feb 2011 06:11:39 -0800 (PST) Received: by 10.229.111.210 with HTTP; Tue, 8 Feb 2011 06:11:39 -0800 (PST) In-Reply-To: <4D514CBB.7010007@viagenie.ca> References: <4D514CBB.7010007@viagenie.ca> Date: Tue, 8 Feb 2011 14:11:39 +0000 Message-ID: From: Erik Kline To: Simon Perreault Content-Type: multipart/alternative; boundary=00163646d5be5bffe5049bc5edcd X-System-Of-Record: true Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:11:37 -0000 --00163646d5be5bffe5049bc5edcd Content-Type: text/plain; charset=UTF-8 On 8 February 2011 14:01, Simon Perreault wrote: > On 2011-02-07 23:41, Cameron Byrne wrote: > > Is it possible that happy eyeballs is not feasible to implement within > > the short time frame that it may be useful? > > Even in a pure IPv6-only world, happy eyeballs would still be useful. > When a name resolves to multiple addresses, trying them in parallel has > advantages over trying them in sequence. > Even is takes 2 years to get out there and broadly adopted by applications / OSes, does anyone think that IPv4 will be virtually eliminated by the 2 year mark? I suppose I could be (pleasantly) surprised, but... --00163646d5be5bffe5049bc5edcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8 February 2011 14:01, Simon Perreault <simon.perreault@viagenie.ca> wrote:
On 2011-02-07 23:41, Cameron Byrne wrote:
> Is it possible that happy eyeballs is not feasible to implement within=
> the short time frame that it may be useful?

Even in a pure IPv6-only world, happy eyeballs would still be useful.=
When a name resolves to multiple addresses, trying them in parallel has
advantages over trying them in sequence.

Even is takes 2 years to get out there and broadly adopted by application= s / OSes, does anyone think that IPv4 will be virtually eliminated by the 2= year mark? =C2=A0I suppose I could be (pleasantly) surprised, but...
--00163646d5be5bffe5049bc5edcd-- From remi.despres@free.fr Tue Feb 8 06:15:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFE7D3A7134 for ; Tue, 8 Feb 2011 06:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[AWL=-0.792, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLrlZ+hB568T for ; Tue, 8 Feb 2011 06:15:08 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by core3.amsl.com (Postfix) with ESMTP id 1282B3A6DED for ; Tue, 8 Feb 2011 06:15:08 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2208.sfr.fr (SMTP Server) with ESMTP id B426170000AE; Tue, 8 Feb 2011 15:15:14 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2208.sfr.fr (SMTP Server) with ESMTP id E3F06700008F; Tue, 8 Feb 2011 15:15:13 +0100 (CET) X-SFR-UUID: 20110208141513933.E3F06700008F@msfrf2208.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D50474D.3030406@brightok.net> Date: Tue, 8 Feb 2011 15:15:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:15:08 -0000 Le 7 f=E9vr. 2011 =E0 20:26, Jack Bates a =E9crit : > On 2/7/2011 1:20 PM, Fred Baker wrote: >>=20 >> I'm very confused. If you are using NPTv6, you have native IPv6 >> service. If you have native IPv6 service, why on earth would you be >> using 6to4? >=20 > I can NAT66 from 2002:: prefixes to my native prefixes (I have native = IPv6 at all ISP 6to4 relays). I'd be using 6to4 in any scenario where a = customer did not support any other IPv6 mechanism (ie, no 6rd support, = no native support). The problem is that, doing that, e2e address transparency, which was = available between two 6to4 addresses, is now broken! New solutions should first avoid breaking uses that already exist.=20 Besides, restored e2e transparency is one of the important new features = of IPv6. Regards, RD =20 From Ted.Lemon@nominum.com Tue Feb 8 06:17:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A043A6D02 for ; Tue, 8 Feb 2011 06:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4S-YZcNEYNw for ; Tue, 8 Feb 2011 06:17:14 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 15BA83A68C0 for ; Tue, 8 Feb 2011 06:17:14 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTVFQcFFw+lg9mBuKUPv3lLikV+b/pwIs@postini.com; Tue, 08 Feb 2011 06:17:21 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 52EE01B83B7 for ; Tue, 8 Feb 2011 06:17:20 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1DA1B190052; Tue, 8 Feb 2011 06:17:20 -0800 (PST) (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; Tue, 8 Feb 2011 06:17:19 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <0BDAB499-AAE2-432B-B7C7-C2F03744FC93@network-heretics.com> Date: Tue, 8 Feb 2011 09:17:15 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <4D514EAB.3070109@brightok.net> <0BDAB499-AAE2-432B-B7C7-C2F03744FC93@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:17:15 -0000 On Feb 8, 2011, at 9:11 AM, Keith Moore wrote: > unfortunately, it might end up killing v6 also. It seems to me that the premise behind this assertion is that you think = that killing 6to4 will kill IPv6. It makes sense that you want 6to4 = for your particular application, but it doesn't make sense to say that = killing 6to4 will kill IPv6. I don't think it adds to the discussion = to overdramatize. From jbates@brightok.net Tue Feb 8 06:17:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33F23A714A for ; Tue, 8 Feb 2011 06:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.064 X-Spam-Level: X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfkayOH5pGMq for ; Tue, 8 Feb 2011 06:17:33 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 0D8CD3A7123 for ; Tue, 8 Feb 2011 06:17:32 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18EHZ38022784; Tue, 8 Feb 2011 08:17:35 -0600 (CST) Message-ID: <4D51507C.9050409@brightok.net> Date: Tue, 08 Feb 2011 08:17:32 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:17:33 -0000 On 2/8/2011 8:15 AM, Rémi Després wrote: > New solutions should first avoid breaking uses that already exist. > I'm up for you providing a solution for CGN + 6to4. Until then, we either break 6to4 completely or we provide a little packet mangling. At least it's only 1:1 NAT. Jack From simon.perreault@viagenie.ca Tue Feb 8 06:18:14 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7592C3A7153 for ; Tue, 8 Feb 2011 06:18:14 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7+quREojG3f for ; Tue, 8 Feb 2011 06:18:13 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 2C93D3A714A for ; Tue, 8 Feb 2011 06:18:13 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c003:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 67D0D20EFE for ; Tue, 8 Feb 2011 09:18:19 -0500 (EST) Message-ID: <4D5150AA.8050902@viagenie.ca> Date: Tue, 08 Feb 2011 09:18:18 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:18:14 -0000 On 2011-02-07 22:50, Fred Baker wrote: > I think the most important question is: what needs to be done before we > decide we are done with this draft? IMHO, we need to decide whether we want to recommend happy eyeballs or not. There were concerns about it breaking determinism, breaking prioritization, etc. Are these issues "deal-breakers", or can happy eyeballs be modified to fix/mitigate them? 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 fred@cisco.com Tue Feb 8 06:25:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F28F3A6407 for ; Tue, 8 Feb 2011 06:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.269 X-Spam-Level: X-Spam-Status: No, score=-110.269 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8VfClsnXIue for ; Tue, 8 Feb 2011 06:25:06 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9A3933A63D2 for ; Tue, 8 Feb 2011 06:25:06 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM/gUE2rR7H+/2dsb2JhbAClL3OgT5s2hVoEhHuGb4Mu Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 08 Feb 2011 14:25:11 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p18EP7MP003634; Tue, 8 Feb 2011 14:25:12 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Tue, 08 Feb 2011 06:25:12 -0800 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Tue, 08 Feb 2011 06:25:12 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Tue, 8 Feb 2011 06:24:58 -0800 Message-Id: <85E0CB2F-FF68-4995-A178-772812FC9181@cisco.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:25:08 -0000 On Feb 8, 2011, at 2:27 AM, R=E9mi Despr=E9s wrote: > Le 7 f=E9vr. 2011 =E0 20:11, Fred Baker a =E9crit : >> often has a broken PMTU implementation due to ICMPv6 filtering >=20 > AFAIK, broken PMTUD isn't due to 6rd, but more data on this subject = are welcome. > Anyway, that's the reason to stay with 1280 (still permitting = application-layer datagrams to be much larger). I think we're agreeing on that. I suggested that PMTUD is often broken = when folks filter ICMPv6, and ICMPv6 Destination Unreachables often = happen when a datagram hits a tunnel. In my case, the tunnel has = something to do with Hurricane Electric; in the 6rd case, it's an = IPv6/IPv4 encapsulation. Either way, if the sender of the datagram can't = receive the signal to reduce its datagram size, it won't, and the = receiver won't get its datagrams.= From Ted.Lemon@nominum.com Tue Feb 8 06:31:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 835623A659C for ; Tue, 8 Feb 2011 06:31:15 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBX-mWLJO5BR for ; Tue, 8 Feb 2011 06:31:14 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 71A0F3A6407 for ; Tue, 8 Feb 2011 06:31:14 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTVFTuL6mzCgSAryVtuqqGYBevKmVkBEP@postini.com; Tue, 08 Feb 2011 06:31:21 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1D46F1B83B3 for ; Tue, 8 Feb 2011 06:31:19 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id DDBE9190052; Tue, 8 Feb 2011 06:31:18 -0800 (PST) (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; Tue, 8 Feb 2011 06:31:18 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4D51507C.9050409@brightok.net> Date: Tue, 8 Feb 2011 09:31:13 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:31:15 -0000 On Feb 8, 2011, at 9:17 AM, Jack Bates wrote: > I'm up for you providing a solution for CGN + 6to4. Until then, we = either break 6to4 completely or we provide a little packet mangling. At = least it's only 1:1 NAT. A replacement that doesn't deliver the functionality that the thing it = replaces delivers is not a replacement. The right solution to the = problem is the one Keith describes: don't deploy CGN without v6. Of = course, v6ops is not in a position to mandate this, and indeed I suspect = that there is no consensus in the working group that this even matters. = But let us at least agree on what we are talking about, and not pretend = that non-solutions are solutions. From jbates@brightok.net Tue Feb 8 06:36:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0993A676A for ; Tue, 8 Feb 2011 06:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZAxEDZKo513 for ; Tue, 8 Feb 2011 06:36:12 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 550483A659C for ; Tue, 8 Feb 2011 06:36:12 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18EaI7l026915; Tue, 8 Feb 2011 08:36:18 -0600 (CST) Message-ID: <4D5154E1.60000@brightok.net> Date: Tue, 08 Feb 2011 08:36:17 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ted Lemon References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> In-Reply-To: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:36:13 -0000 On 2/7/2011 10:11 PM, Ted Lemon wrote: > I've already stated a preference for a non-heuristic solution, where you just try everything at once. The problem with that outside of server load is the IPv4 CGN load as we move into a more IPv6 world. I haven't had time to fully read the draft, but I do hope that it properly closes all channels it won't use for the sake of CGN tables. Jack From fred@cisco.com Tue Feb 8 06:39:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A2D3A6452 for ; Tue, 8 Feb 2011 06:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g1ZjjqORgbJ for ; Tue, 8 Feb 2011 06:39:52 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E6FCE3A6403 for ; Tue, 8 Feb 2011 06:39:52 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFPkUE2rRN+K/2dsb2JhbAClL3OgUps3gn2CXQSEe4Zvgy4 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 08 Feb 2011 14:40:00 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p18EdtrU027447; Tue, 8 Feb 2011 14:39:59 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Tue, 08 Feb 2011 06:40:00 -0800 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Tue, 08 Feb 2011 06:40:00 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D5150AA.8050902@viagenie.ca> Date: Tue, 8 Feb 2011 06:39:45 -0800 Message-Id: <9CF035D9-E178-4721-A089-A71EDF9CA1BE@cisco.com> References: <4D5150AA.8050902@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:39:53 -0000 On Feb 8, 2011, at 6:18 AM, Simon Perreault wrote: > On 2011-02-07 22:50, Fred Baker wrote: >> I think the most important question is: what needs to be done before = we >> decide we are done with this draft? >=20 > IMHO, we need to decide whether we want to recommend happy eyeballs or > not. There were concerns about it breaking determinism, breaking > prioritization, etc. Are these issues "deal-breakers", or can happy > eyeballs be modified to fix/mitigate them? Speaking strictly for myself, I think the determinism and prioritization = (by which I presume you meant RFC 3484) were solutions to a problem that = Arifumi et al (draft-ietf-6man-rfc3484-revise) have been very clear = remains unfixed. Happy Eyeballs is a different and (IMHO) better fix for = that problem. The problem is that if a system has multiple addresses = (multiple IPv6 addresses, IPv4 along with IPv6, or multiple IPv4) and = that path associated with one is broken (failure, filter, whatever), and = if we agree that ultimately the objective is to open a session with that = system, then we need to quickly identify an address pair that works in = the context of the actual working path and the various routing policies = enacted along it. =46rom my perspective, RFC 3484 and its bis should be = about the order in which addresses are tried, but we also need to deal = with the failure cases, which H.E. points out remain broken.= From Ted.Lemon@nominum.com Tue Feb 8 06:40:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ABA63A676A for ; Tue, 8 Feb 2011 06:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMidCzxrP6S1 for ; Tue, 8 Feb 2011 06:40:02 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 8C3303A6403 for ; Tue, 8 Feb 2011 06:40:02 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTVFVyf8PyhyzOigQqWJepSgV9pbmHl5i@postini.com; Tue, 08 Feb 2011 06:40:09 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F13D01B839F for ; Tue, 8 Feb 2011 06:40:08 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id EADD9190052; Tue, 8 Feb 2011 06:40:08 -0800 (PST) (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; Tue, 8 Feb 2011 06:40:08 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4D5150AA.8050902@viagenie.ca> Date: Tue, 8 Feb 2011 09:40:04 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <4E8CAF8B-4CB9-41CE-9880-1DB78C40EF7C@nominum.com> References: <4D5150AA.8050902@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:40:03 -0000 On Feb 8, 2011, at 9:18 AM, Simon Perreault wrote: > IMHO, we need to decide whether we want to recommend happy eyeballs or > not. There were concerns about it breaking determinism, breaking > prioritization, etc. Are these issues "deal-breakers", or can happy > eyeballs be modified to fix/mitigate them? Happy Eyeballs as written actually doesn't break determinism, because it = prefers the means of connection that worked last time. I argued = against this last night because I couldn't figure out a good way to = implement it, but sometime last night it sunk in to me what problem the = preference algorithm in Happy Eyeballs was meant to solve, and I = realized that it isn't as hard to implement as I'd assumed (there's no = need to implement host-wide state). I think you're right that we do need to decide whether to recommend = Happy Eyeballs. I do not think there are any deal-breakers. I think = there are a few tweaks needed to the draft before it's done, but we are = on the right track. From Ted.Lemon@nominum.com Tue Feb 8 06:42:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B05513A6403 for ; Tue, 8 Feb 2011 06:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aU8WESeDr9oE for ; Tue, 8 Feb 2011 06:42:39 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id C20613A63EB for ; Tue, 8 Feb 2011 06:42:38 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTVFWZUJms0r60RKVCsuMENWw91N3MkBm@postini.com; Tue, 08 Feb 2011 06:42:46 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 606DC1B83A2 for ; Tue, 8 Feb 2011 06:42:45 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 59D3D190055; Tue, 8 Feb 2011 06:42:45 -0800 (PST) (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; Tue, 8 Feb 2011 06:42:45 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4D5154E1.60000@brightok.net> Date: Tue, 8 Feb 2011 09:42:40 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <900E5BAD-EBF3-4F73-96AE-616DDA760A79@nominum.com> References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:42:39 -0000 On Feb 8, 2011, at 9:36 AM, Jack Bates wrote: > The problem with that outside of server load is the IPv4 CGN load as = we move into a more IPv6 world. I haven't had time to fully read the = draft, but I do hope that it properly closes all channels it won't use = for the sake of CGN tables. Okay, that's an excellent argument for not deploying CGNs without = parallel IPv6 connectivity. I don't think it says anything about Happy = Eyeballs, though. Since typically you'd be trying an IPv4 and an IPv6 = connection in parallel, the total state maintained by the CGN ought to = be the same--just the IPv4 part. From jbates@brightok.net Tue Feb 8 07:03:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09B513A65A6 for ; Tue, 8 Feb 2011 07:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.213 X-Spam-Level: X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPlZjVh5qB0G for ; Tue, 8 Feb 2011 07:03:27 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 67CCE3A6774 for ; Tue, 8 Feb 2011 07:03:25 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18F3T0s003448; Tue, 8 Feb 2011 09:03:30 -0600 (CST) Message-ID: <4D515B41.7060409@brightok.net> Date: Tue, 08 Feb 2011 09:03:29 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> <1297147875.4205.34.camel@shakira.millnert.se> <1987A727-BD2F-4BAB-AB59-ED27033CE17F@network-heretics.com> In-Reply-To: <1987A727-BD2F-4BAB-AB59-ED27033CE17F@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:03:28 -0000 On 2/8/2011 12:57 AM, Keith Moore wrote: > 6to4 is not the problem; the problem is breaking fundamental design > assumptions in IP. It's not like 6to4 is the only thing in the v4 > Internet that expects globally scoped addresses to be uniquely > assigned to hosts. Except that ARIN is proposing a /10 for this specific purpose (since it failed the IETF). It will be just as broken with 6to4; as 6to4 uses a hack to disable (RFC-1918 awareness) and using RFC-1918 for a CGN is even worse than breaking 6to4. Failed protocol. Someone should have set a flag for an ISP to specify support or no support for 6to4, even a simple dns query would have done. Too late now, operators will just break it. I realize their IPv6 trial doesn't help the thousands of clueless windows 7 users, which is why the easiest hack is for t-mobile to support 6to4 anycast + NAT66, but I doubt they have an implementation for that yet. Now, here's the import part. Rolling out pure IPv6 to everyone will create it's own brokenness (6to4 policy is less used than pure IPv6 policy). It will happen soon, but we aren't quite to that point yet and there is a LOT of isolation issues. Jack From jbates@brightok.net Tue Feb 8 07:06:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 203653A679C for ; Tue, 8 Feb 2011 07:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.214 X-Spam-Level: X-Spam-Status: No, score=-3.214 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyl+9dMsmlAD for ; Tue, 8 Feb 2011 07:06:12 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 391C13A6774 for ; Tue, 8 Feb 2011 07:06:12 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p18F6HHA000875; Tue, 8 Feb 2011 09:06:17 -0600 (CST) Message-ID: <4D515BE8.8090904@brightok.net> Date: Tue, 08 Feb 2011 09:06:16 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <20110208073126.GA18776@srv03.cluenet.de> <1C37F0A2-88C6-4CB3-B624-608E0B7364F1@network-heretics.com> In-Reply-To: <1C37F0A2-88C6-4CB3-B624-608E0B7364F1@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:06:13 -0000 I allocate IP addresses at 95%+ utilization. What optimizations? Jack On 2/8/2011 7:40 AM, Keith Moore wrote: > I don't really buy "need to". There are lots of ways to better > allocate existing IPv4 addresses that are probably applicable to most > networks. What I accept is that CGN is the current fad. From jbates@brightok.net Tue Feb 8 07:12:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E713A67A2 for ; Tue, 8 Feb 2011 07:12:42 -0800 (PST) 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.049, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3FX8v8kcj4F for ; Tue, 8 Feb 2011 07:12:41 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id B7CE93A6774 for ; Tue, 8 Feb 2011 07:12:41 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18FCl0G005748; Tue, 8 Feb 2011 09:12:48 -0600 (CST) Message-ID: <4D515D6F.9050708@brightok.net> Date: Tue, 08 Feb 2011 09:12:47 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ted Lemon References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <900E5BAD-EBF3-4F73-96AE-616DDA760A79@nominum.com> In-Reply-To: <900E5BAD-EBF3-4F73-96AE-616DDA760A79@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:12:42 -0000 On 2/8/2011 8:42 AM, Ted Lemon wrote: > Okay, that's an excellent argument for not deploying CGNs without > parallel IPv6 connectivity. I don't think it says anything about > Happy Eyeballs, though. Since typically you'd be trying an IPv4 and > an IPv6 connection in parallel, the total state maintained by the CGN > ought to be the same--just the IPv4 part. > You still have to properly close the connections. A proper IPv4 connection through CGN answers the request, transmits data, and then closes. You will turn TCP into UDP if you don't close the connection properly so that the CGN can remove the entry. Also, this has nothing to do with IPv6 connectivity while running a CGN. Happy eyeballs will happily use both protocols at the same time. Jack From jbates@brightok.net Tue Feb 8 07:19:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36ED03A67C3 for ; Tue, 8 Feb 2011 07:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rES-RNAHAYv1 for ; Tue, 8 Feb 2011 07:19:00 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 606A43A6407 for ; Tue, 8 Feb 2011 07:19:00 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p18FJ40F004219; Tue, 8 Feb 2011 09:19:04 -0600 (CST) Message-ID: <4D515EE7.1080008@brightok.net> Date: Tue, 08 Feb 2011 09:19:03 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ted Lemon References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> In-Reply-To: <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:19:01 -0000 On 2/8/2011 8:31 AM, Ted Lemon wrote: > A replacement that doesn't deliver the functionality that the thing > it replaces delivers is not a replacement. The right solution to > the problem is the one Keith describes: don't deploy CGN without v6. > Of course, v6ops is not in a position to mandate this, and indeed I > suspect that there is no consensus in the working group that this > even matters. But let us at least agree on what we are talking > about, and not pretend that non-solutions are solutions. > Deploying native IPv6 with the LSN still isn't effective. Currently, in some cases, it will cause more breakage than breaking 6to4. With native IPv6, AAAA is almost ALWAYS preferred over A, where as 6to4 only uses AAAA when there is no A or if there is a 6to4 AAAA. Don't get me wrong, we are getting there, but just throwing users on a broken IPv6 network is not cost effective. Not deploying LSN is not an option. When you are out of space, you are out of space. LSN actually breaks less for the majority of customers than deploying native IPv6 has. This is slowly changing as IPv6 isolation and pathing is resolved and the networks upgrade. Until core networks fix themselves, it will still be a mess for edges and content providers. Jack From tore.anderson@redpill-linpro.com Tue Feb 8 07:36:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555B03A67B7 for ; Tue, 8 Feb 2011 07:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4miACWSanED for ; Tue, 8 Feb 2011 07:36:15 -0800 (PST) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by core3.amsl.com (Postfix) with ESMTP id E971A3A6765 for ; Tue, 8 Feb 2011 07:36:14 -0800 (PST) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 37DC31DD793; Tue, 8 Feb 2011 16:36:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mailhub.linpro.no Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id ZpRvMm4ObbKU; Tue, 8 Feb 2011 16:36:13 +0100 (CET) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Tue, 8 Feb 2011 16:36:06 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 41AF3170C00E; Tue, 8 Feb 2011 16:36:06 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8nD7m5+ozpj; Tue, 8 Feb 2011 16:36:05 +0100 (CET) Received: from envy.fud.no (46.66.94.199.tmi.telenormobil.no [46.66.94.199]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 4C367170C00D; Tue, 8 Feb 2011 16:36:05 +0100 (CET) Message-ID: <4D5162E4.1020606@redpill-linpro.com> Date: Tue, 08 Feb 2011 16:36:04 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> In-Reply-To: <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:36:16 -0000 Hi, * Keith Moore > 6to4 is not harmful to IPv6 deployment. ISPs that break IPv4 are > harmful to IPv6 deployment. 6to4 was the major reason why I had to delay deploying AAAAs for the sites I host. Instead of being able to deploy, I had to run around for more than a year begging hardware and OS vendors to turn it off. So yes, 6to4 is very harmful to people wanting to deploy IPv6. Why do you think «World IPv6 Day» is seen as necessary? >> 6to4 is what is distracting us. having to fix brokenness triggered >> by 6to4. Precisely. > I think the statement in a nutshell is this: as long as operators > insist on seeing 6to4 as a 'problem' rather than a way to provide > their customers good service and a useful transition tool, they're > going to keep sabotaging it. By doing so they're actually impairing > deployment of IPv6. Reverse 6to4 relays deployed close to the content? Check. That doesn't fix the problem, though. There's nothing I, or any other individual network operator, can do to fix it. In order for 6to4 to work reliably, *everyone* must play along. And that's simply not going to happen. 6to4 was a fun little toy for people who wanted to experiment with IPv6. It is completely unsuitable to be Mr. John Q. Public's generic IPv6 internet connectivity. At this point in time, *real* IPv6 deployments is necessary, and 6to4 is just getting in the way. It's time to shelve it. Regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From Ted.Lemon@nominum.com Tue Feb 8 07:38:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C593A67E4 for ; Tue, 8 Feb 2011 07:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrMD-d0G77du for ; Tue, 8 Feb 2011 07:38:01 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 9DC063A67CC for ; Tue, 8 Feb 2011 07:38:01 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTVFjYIF5ASrq0PneYndpflF/0rc5XMEq@postini.com; Tue, 08 Feb 2011 07:38:09 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 06A7A1B83B0 for ; Tue, 8 Feb 2011 07:38:08 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E735E190052; Tue, 8 Feb 2011 07:38:07 -0800 (PST) (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; Tue, 8 Feb 2011 07:38:07 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4D515D6F.9050708@brightok.net> Date: Tue, 8 Feb 2011 10:38:03 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <7E1FABAC-2F86-40CE-A56E-57D123143CB0@nominum.com> References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <900E5BAD-EBF3-4F73-96AE-616DDA760A79@nominum.com> <4D515D6F.9050708@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:38:02 -0000 On Feb 8, 2011, at 10:12 AM, Jack Bates wrote: > You still have to properly close the connections. A proper IPv4 = connection through CGN answers the request, transmits data, and then = closes. You will turn TCP into UDP if you don't close the connection = properly so that the CGN can remove the entry. Are you proposing that I might somehow just leave the connection = dangling open, or something else? Even in the case where I leave the = socket open, the load is the same as without happy eyeballs, since no = additional IPv4 connections have been opened. But I don't even see how = I'd do that--as soon as I have a valid connection, I'm going to close = the socket, at which point the O.S. should start closing the connection, = and that should delete the state from the NAT. Can you expand on the failure mode you're concerned about here? From Ted.Lemon@nominum.com Tue Feb 8 07:40:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99293A67CC for ; Tue, 8 Feb 2011 07:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV04j5AM1imo for ; Tue, 8 Feb 2011 07:40:33 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id D06683A6765 for ; Tue, 8 Feb 2011 07:40:32 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTVFj93OzPGWPfp5ZtFQneHHT/0B4+Jtc@postini.com; Tue, 08 Feb 2011 07:40:40 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3F1A91B83B0 for ; Tue, 8 Feb 2011 07:40:39 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 33EAA190052; Tue, 8 Feb 2011 07:40:39 -0800 (PST) (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; Tue, 8 Feb 2011 07:40:38 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4D515EE7.1080008@brightok.net> Date: Tue, 8 Feb 2011 10:40:34 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> <4D515EE7.1080008@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:40:33 -0000 On Feb 8, 2011, at 10:19 AM, Jack Bates wrote: > Deploying native IPv6 with the LSN still isn't effective. Currently, = in some cases, it will cause more breakage than breaking 6to4. With = native IPv6, AAAA is almost ALWAYS preferred over A, where as 6to4 only = uses AAAA when there is no A or if there is a 6to4 AAAA. I'm not following your argument here. Presumably if you get a AAAA, = and you have v6 connectivity, you will connect successfully. If you = get an A and an AAAA, you will still connect successfully. And if you = get an A, you *might* connect successfully, if the LSN isn't overloaded, = and if the NAT doesn't break something simply because it modified the = packets in transit. Where's the case where adding working v6 makes = things worse? From jbates@brightok.net Tue Feb 8 07:45:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86DA63A67F3 for ; Tue, 8 Feb 2011 07:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxF8fFQMv7Km for ; Tue, 8 Feb 2011 07:45:35 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 9BBC73A67F1 for ; Tue, 8 Feb 2011 07:45:35 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18FjdhJ014165; Tue, 8 Feb 2011 09:45:39 -0600 (CST) Message-ID: <4D516522.9050007@brightok.net> Date: Tue, 08 Feb 2011 09:45:38 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ted Lemon References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> <4D515EE7.1080008@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:45:36 -0000 On 2/8/2011 9:40 AM, Ted Lemon wrote: > I'm not following your argument here. Presumably if you get a AAAA, > and you have v6 connectivity, you will connect successfully. If you > get an A and an AAAA, you will still connect successfully. And if > you get an A, you *might* connect successfully, if the LSN isn't > overloaded, and if the NAT doesn't break something simply because it > modified the packets in transit. Where's the case where adding > working v6 makes things worse? > Grandma goes to some website that has AAAA advertised and their IPv6 address isn't on my Internet. Grandma hits a DNS load balancer that responds to AAAA with nxdomain. For every customer I turn up on IPv6, I find more brokenness. Jack From jbates@brightok.net Tue Feb 8 07:47:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31413A67F5 for ; Tue, 8 Feb 2011 07:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.212 X-Spam-Level: X-Spam-Status: No, score=-3.212 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjrAVvbPLt-6 for ; Tue, 8 Feb 2011 07:47:39 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 3A45E3A67F4 for ; Tue, 8 Feb 2011 07:47:39 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18Fl0HM014502; Tue, 8 Feb 2011 09:47:00 -0600 (CST) Message-ID: <4D516573.6070407@brightok.net> Date: Tue, 08 Feb 2011 09:46:59 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ted Lemon References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <900E5BAD-EBF3-4F73-96AE-616DDA760A79@nominum.com> <4D515D6F.9050708@brightok.net> <7E1FABAC-2F86-40CE-A56E-57D123143CB0@nominum.com> In-Reply-To: <7E1FABAC-2F86-40CE-A56E-57D123143CB0@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:47:40 -0000 On 2/8/2011 9:38 AM, Ted Lemon wrote: > Are you proposing that I might somehow just leave the connection > dangling open, or something else? Even in the case where I leave Every case I've seen discussing happy eyeballs implementation has pointed out that the modification needs to be made in the stack itself, so the application wouldn't be closing the socket, as the application would have a single socket. Jack From simon.perreault@viagenie.ca Tue Feb 8 07:49:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0132E3A67F6 for ; Tue, 8 Feb 2011 07:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isQyymn3nisV for ; Tue, 8 Feb 2011 07:49:24 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 2190B3A67E5 for ; Tue, 8 Feb 2011 07:49:24 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4D17720D35; Tue, 8 Feb 2011 10:49:30 -0500 (EST) Message-ID: <4D516609.3070805@viagenie.ca> Date: Tue, 08 Feb 2011 10:49:29 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jack Bates References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <900E5BAD-EBF3-4F73-96AE-616DDA760A79@nominum.com> <4D515D6F.9050708@brightok.net> <7E1FABAC-2F86-40CE-A56E-57D123143CB0@nominum.com> <4D516573.6070407@brightok.net> In-Reply-To: <4D516573.6070407@brightok.net> 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] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:49:26 -0000 On 2011-02-08 10:46, Jack Bates wrote: > Every case I've seen discussing happy eyeballs implementation has > pointed out that the modification needs to be made in the stack itself, That would be wrong. Happy eyeballs should define externally-observable host behaviour, not implementation details. 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 ichiroumakino@gmail.com Tue Feb 8 08:00:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152583A63D3 for ; Tue, 8 Feb 2011 08:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZXsixvfIzU9 for ; Tue, 8 Feb 2011 08:00:32 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id C3E7F3A63D2 for ; Tue, 8 Feb 2011 08:00:31 -0800 (PST) Received: by ewy8 with SMTP id 8so3312647ewy.31 for ; Tue, 08 Feb 2011 08:00:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=o8FpZV6KrQWgEqF0Wr+chl/9j6GGd/fAJhVHXl2ivxU=; b=kAobeBNUTMUCHEZzktUYPbV7ekJpd9I0cR9PFesGyQqPcgWuXwSNXNb3IkZ0Oxdp6A 7UyQyYHKb1AkVs/SEu/PddR4qylhgrFH9JTtNe68rzKYW4yAXQ0uVSuVTdlA5Zgc+IFM O6ltJnZiyOCmcIzhnlUI/vbEooFMARXWGZdaw= 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=Yvq7a34DsQgITxtCMZAya4kMVZCxNhmAC7ENQefs7gG+neE0RI8BoOVEK5MzheJJER 1gKedrByNWVz/dScjHED8i0/mmVkCxoVbNklg6a1d5zq7DrvTtwm54WTYqMDTo/sn6vW xjUE4w7Y1wfX7Fshe48LnfhCjVigzlAYRlFY0= Received: by 10.213.34.5 with SMTP id j5mr201252ebd.27.1297180838099; Tue, 08 Feb 2011 08:00:38 -0800 (PST) Received: from dhcp-10-61-105-105.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id q52sm4099517eei.9.2011.02.08.08.00.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Feb 2011 08:00:37 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> Date: Tue, 8 Feb 2011 17:00:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:00:34 -0000 Keith, >> 6to4 model 1 is not (and has never been) deployed (basically = recreates the 6bone). >=20 > Incorrect on both counts. examples please. >> 6to4 model 2, even with a consenting forward relay suffers the same = issues on the reverse path. >> in my view 6to4 is not salvageable.=20 >=20 > Perhaps that's because you haven't tried to identify solutions? it is = possible, for instance, to identify and marginalize broken relay = routers. how? the problem with relays routers are that they depend on charity by 3rd = parties. it is difficult to see the motivation for anyone to run a relay = router in the first place. if I thought 6to4 could be fixed I would have suggested the fixes. you = seem so convinced that there are fixes, can you please share those? [...] > 6to4 provides a way for anyone with any properly working IPv4 connect = to connect to any IPv6 host. That's a huge win. It eliminates one of = the barriers toward IPv6 acceptance by providing a means for universal = access to IPv6 over any properly working IPv4 connection. unfortunately that's not the end-user experience that has been shown. http://www.google.com/trends?q=3Ddisable+ipv6,+enable+ipv6 (;-)) = http://readonly.labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really [...] > No, 6to4 is not broken. 6to4 is just sending IP packets and = expecting them to get to the hosts associated with their destination = addresses intact. >=20 > The network is broken because of many brain damaged practices in place = for other reasons, and 6to4 is one of many things suffering because of = it. =20 >=20 > (I sometimes suspect that 6to4 is also suffering because some = operators see it as an end-run around them, so they don't mind = implementing measures that penalize it. But that's not a problem with = 6to4....) I have seen no evidence that operators are actively blocking 6to4. 6to4 depends on the charity of others. unfortunately that's not a = realistic deployment model. >>> Note that I am *not* trying to unnaturally prolong the life of 6to4 = or >>> Anycast 6to4. A good way to get rid of them is for all ISPs to = deploy IPv6, >>> for example. >>=20 >> and until that happens (SP deploys IPv6), IPv6 deployment will not = happen. 6to4 does not in any way accelerate IPv6 deployment. >=20 > Completely incorrect. See above. >=20 > I think the statement in a nutshell is this: as long as operators = insist on seeing 6to4 as a 'problem' rather than a way to provide their = customers good service and a useful transition tool, they're going to = keep sabotaging it. By doing so they're actually impairing deployment = of IPv6. I have seen no evidence of sabotage. all the brokenness I have seen have been caused by "this is how the = 6to4/Internet works". your nearest relay is on a different continent, = one of the relays on the path are overloaded, ICMP messages are = blackholed, ICMP messages are blocked, bogus addresses are used, the = 6to4 relay is behind some Enterprise firewall... and so on... I just don't understand how we can get the whole IPv4 Internet fixed, = plus get 6to4 deployed with relays in such a fashion that it works on = reasonably equal terms with IPv4. as you appear to have very strong opinions that 6to4 has a right of = life... can you please explain how we can make it a successful protocol. = where successful is almost equal to deployable. cheers, Ole= From jbates@brightok.net Tue Feb 8 08:03:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461963A67E5 for ; Tue, 8 Feb 2011 08:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.213 X-Spam-Level: X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSsfaCmd3v0v for ; Tue, 8 Feb 2011 08:03:58 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 7B3733A67B5 for ; Tue, 8 Feb 2011 08:03:58 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18G45jP019005; Tue, 8 Feb 2011 10:04:05 -0600 (CST) Message-ID: <4D516974.8060107@brightok.net> Date: Tue, 08 Feb 2011 10:04:04 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Simon Perreault References: <4D514CBB.7010007@viagenie.ca> In-Reply-To: <4D514CBB.7010007@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:03:59 -0000 On 2/8/2011 8:01 AM, Simon Perreault wrote: > On 2011-02-07 23:41, Cameron Byrne wrote: >> Is it possible that happy eyeballs is not feasible to implement within >> the short time frame that it may be useful? > > Even in a pure IPv6-only world, happy eyeballs would still be useful. > When a name resolves to multiple addresses, trying them in parallel has > advantages over trying them in sequence. > Correct me if I'm wrong, but where does it say that you should connect to ALL addresses within a family? Also, I'd prefer the round robin effect back, personally. Jack From Ted.Lemon@nominum.com Tue Feb 8 08:04:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5753D3A67FB for ; Tue, 8 Feb 2011 08:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+OCDxodnKqX for ; Tue, 8 Feb 2011 08:04:05 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 154923A67EB for ; Tue, 8 Feb 2011 08:04:05 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTVFpe2qg8mRlj944j5oCCOLMh+cAQRcp@postini.com; Tue, 08 Feb 2011 08:04:12 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6F17C1B83BB for ; Tue, 8 Feb 2011 08:04:11 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5C3E1190052; Tue, 8 Feb 2011 08:04:11 -0800 (PST) (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; Tue, 8 Feb 2011 08:04:10 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4D516573.6070407@brightok.net> Date: Tue, 8 Feb 2011 11:04:06 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <5F8D7E05-7830-4855-BBC0-519EB60C0782@nominum.com> References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <900E5BAD-EBF3-4F73-96AE-616DDA760A79@nominum.com> <4D515D6F.9050708@brightok.net> <7E1FABAC-2F86-40CE-A56E-57D123143CB0@nominum.com> <4D516573.6070407@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:04:06 -0000 On Feb 8, 2011, at 10:46 AM, Jack Bates wrote: > Every case I've seen discussing happy eyeballs implementation has = pointed out that the modification needs to be made in the stack itself, = so the application wouldn't be closing the socket, as the application = would have a single socket. Then you haven't been following the discussion very closely, because = that's certainly not how I would propose to implement happy eyeballs, = nor is it how the happy eyeballs draft proposes to implement it = (although it does propose a different implementation than I would). I think Fred suggested a library or system call called "connect_to_name" = that someone may have suggested would take a socket descriptor as an = input. I would agree that that's the wrong way to solve the problem. = But Fred's solution works fine as long as connect_to_name *returns* the = socket that connected, and takes no sockets as input. From simon.perreault@viagenie.ca Tue Feb 8 08:10:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1795F3A67F3 for ; Tue, 8 Feb 2011 08:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtIEiCaNXZWb for ; Tue, 8 Feb 2011 08:10:00 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id C1BF13A67EC for ; Tue, 8 Feb 2011 08:09:59 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 20DDA20D35; Tue, 8 Feb 2011 11:10:06 -0500 (EST) Message-ID: <4D516ADD.5000804@viagenie.ca> Date: Tue, 08 Feb 2011 11:10:05 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jack Bates References: <4D514CBB.7010007@viagenie.ca> <4D516974.8060107@brightok.net> In-Reply-To: <4D516974.8060107@brightok.net> 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] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:10:01 -0000 On 2011-02-08 11:04, Jack Bates wrote: > Correct me if I'm wrong, but where does it say that you should connect > to ALL addresses within a family? You're right. The text should make this explicit. Adding an example with multiple IPvX addresses would also be nice. > Also, I'd prefer the round robin effect back, personally. With appropriate randomization and (small) delay between connection attempts, it won't go away. 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 jav@sics.se Tue Feb 8 08:12:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92BC3A67D3 for ; Tue, 8 Feb 2011 08:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MGCanUtqqR0 for ; Tue, 8 Feb 2011 08:12:49 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id E3BF53A67C2 for ; Tue, 8 Feb 2011 08:12:48 -0800 (PST) Received: from [193.10.66.199] (dab.sics.se [193.10.66.199]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id AC0434031C; Tue, 8 Feb 2011 17:12:55 +0100 (CET) From: Javier Ubillos To: Ted Lemon In-Reply-To: <5F8D7E05-7830-4855-BBC0-519EB60C0782@nominum.com> References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <900E5BAD-EBF3-4F73-96AE-616DDA760A79@nominum.com> <4D515D6F.9050708@brightok.net> <7E1FABAC-2F86-40CE-A56E-57D123143CB0@nominum.com> <4D516573.6070407@brightok.net> <5F8D7E05-7830-4855-BBC0-519EB60C0782@nominum.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 08 Feb 2011 17:12:56 +0100 Message-ID: <1297181576.2115.25.camel@dab> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:12:49 -0000 On Tue, 2011-02-08 at 11:04 -0500, Ted Lemon wrote: > On Feb 8, 2011, at 10:46 AM, Jack Bates wrote: > > Every case I've seen discussing happy eyeballs implementation has pointed out that the modification needs to be made in the stack itself, so the application wouldn't be closing the socket, as the application would have a single socket. > > Then you haven't been following the discussion very closely, because that's certainly not how I would propose to implement happy eyeballs, nor is it how the happy eyeballs draft proposes to implement it (although it does propose a different implementation than I would). > > I think Fred suggested a library or system call called "connect_to_name" that someone may have suggested would take a socket descriptor as an input. I would agree that that's the wrong way to solve the problem. But Fred's solution works fine as long as connect_to_name *returns* the socket that connected, and takes no sockets as input. For what it's worth, we are currently working on a happy-eyeballs implementation for name-based sockets. It takes a name (FQDN) as an input, and provides a socket (AF_NAME). It uses "normal" BSD-semantics. The name is provided in an sockaddr struct (sockaddr_name to be specific). The application opens up a single socket. THe socket in turn tries two subsockets (one for each address family). And whichever is _not_ chosen is gracefully closed (RST). // Javier > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Tue Feb 8 08:22:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3AC53A67F9 for ; Tue, 8 Feb 2011 08:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huiu5Tc2eLDZ for ; Tue, 8 Feb 2011 08:22:43 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id E205B3A67E3 for ; Tue, 8 Feb 2011 08:22:43 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 21DB1D0C66B8 for ; Tue, 8 Feb 2011 08:22:51 -0800 (PST) X-AuditID: 11807134-b7c40ae000006cb9-99-4d516dda44ba Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay14.apple.com (Apple SCV relay) with SMTP id 2D.D1.27833.ADD615D4; Tue, 8 Feb 2011 08:22:51 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.39.232.117] (166-205-138-185.mobile.mymmode.com [166.205.138.185]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LGB00GW545YRG90@et.apple.com> for v6ops@ietf.org; Tue, 08 Feb 2011 08:22:50 -0800 (PST) References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> In-reply-to: <4D5154E1.60000@brightok.net> Message-id: <6B3B9302-48C6-406A-BAFC-2AC62ABB29AF@apple.com> X-Mailer: iPhone Mail (8C148a) From: james woodyatt Date: Tue, 08 Feb 2011 08:22:40 -0800 To: Jack Bates X-Brightmail-Tracker: AAAAAA== Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:22:44 -0000 This comment reminds me strongly of an aphorism the great Canadian science fiction author William Gibson coined: "the street find its own uses for things." Operators who expect even well-intentioned applications to be fair in their dealings with scarce resources in subscriber aggregating NAT gateways, to say nothing of the malicious applications, are whistling past a graveyard. In this particular case, we can expect that happy-eyeballs implementations will more often than not close unused connection attempts in an orderly fashion, but hosts and networks get interrupted all the time in the real world, and exceptions will be frequent. I wouldn't want to be swimming against that tide. --jhw (sent from my phone) On Feb 8, 2011, at 6:36, Jack Bates wrote: > > > On 2/7/2011 10:11 PM, Ted Lemon wrote: >> I've already stated a preference for a non-heuristic solution, where you just try everything at once. > > The problem with that outside of server load is the IPv4 CGN load as we move into a more IPv6 world. I haven't had time to fully read the draft, but I do hope that it properly closes all channels it won't use for the sake of CGN tables. > > > Jack > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jbates@brightok.net Tue Feb 8 08:23:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0F83A67CC for ; Tue, 8 Feb 2011 08:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.215 X-Spam-Level: X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUbOrxMAre8Y for ; Tue, 8 Feb 2011 08:23:09 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id F32F63A67F9 for ; Tue, 8 Feb 2011 08:23:08 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18GNFRe024069; Tue, 8 Feb 2011 10:23:15 -0600 (CST) Message-ID: <4D516DF3.9060407@brightok.net> Date: Tue, 08 Feb 2011 10:23:15 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Simon Perreault References: <4D514CBB.7010007@viagenie.ca> <4D516974.8060107@brightok.net> <4D516ADD.5000804@viagenie.ca> In-Reply-To: <4D516ADD.5000804@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:23:13 -0000 On 2/8/2011 10:10 AM, Simon Perreault wrote: > With appropriate randomization and (small) delay between connection > attempts, it won't go away. > Actually, some address selection implementations completely broke it. See google concerning Vista and DNS. Jack From Fred.L.Templin@boeing.com Tue Feb 8 08:24:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683983A6804 for ; Tue, 8 Feb 2011 08:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.368 X-Spam-Level: X-Spam-Status: No, score=-6.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K64kt6quNU3K for ; Tue, 8 Feb 2011 08:24:08 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 8217F3A6801 for ; Tue, 8 Feb 2011 08:24:08 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p18GO9aQ012991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 10:24:10 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p18GO83x017627; Tue, 8 Feb 2011 08:24:08 -0800 (PST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p18GO7wC017600 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 8 Feb 2011 08:24:08 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 8 Feb 2011 08:24:07 -0800 From: "Templin, Fred L" To: Jack Bates Date: Tue, 8 Feb 2011 08:24:05 -0800 Thread-Topic: [v6ops] Out of scope discussion [Fwd:I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] Thread-Index: AcvHJ8+N1p/wpn92RTKmsfNVT9PznQAhDaqg Message-ID: References: <4D4A2401.2020500@gmail.com> <4D508F4E.6080009@brightok.net> In-Reply-To: <4D508F4E.6080009@brightok.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] Out of scope discussion [Fwd:I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:24:09 -0000 > Which $50 CPEs are currently supporting IRON? Maybe you didn't see from a few messages back, but although the CPE would be a natural platform for the IRON client software, IRON will work just fine with unmodified CPEs. All that is needed is for some device in the customer home network to download a piece of software provided by the IRON service provider. That happens all the time today, and requires no CPE equipment vendor cooperation. Thanks - Fred fred.l.templin@boeing.com= From remi.despres@free.fr Tue Feb 8 08:24:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE393A67E3 for ; Tue, 8 Feb 2011 08:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_20=-0.74, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0HQLydArRXi for ; Tue, 8 Feb 2011 08:24:41 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.21]) by core3.amsl.com (Postfix) with ESMTP id B90423A67F9 for ; Tue, 8 Feb 2011 08:24:40 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2313.sfr.fr (SMTP Server) with ESMTP id 30E8F700009A; Tue, 8 Feb 2011 17:24:47 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2313.sfr.fr (SMTP Server) with ESMTP id 5492E7000096; Tue, 8 Feb 2011 17:24:46 +0100 (CET) X-SFR-UUID: 20110208162446346.5492E7000096@msfrf2313.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D51507C.9050409@brightok.net> Date: Tue, 8 Feb 2011 17:24:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:24:41 -0000 Le 8 f=E9vr. 2011 =E0 15:17, Jack Bates a =E9crit : > On 2/8/2011 8:15 AM, R=E9mi Despr=E9s wrote: >> New solutions should first avoid breaking uses that already exist. >>=20 > I'm up for you providing a solution for CGN + 6to4. If you look for 6to4 to be operational behind a CGN, i.e. where there is = no public IPv4 address, I believe you won't find one. If you look for 6to4 clients to have connectivity with all = native-IPv6-address servers without breaking e2e address transparency, I = believe you will find no solution that is incrementally deployable, i.e. = you won't find any real solution. If you look for 6to4 clients to have such connectivity with all native = IPv6 addresses that e2e connectivity is broken, I believe customers = should be advised to avoid ISPs that do that. Regards, RD From Ted.Lemon@nominum.com Tue Feb 8 08:28:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 765EF3A672E for ; Tue, 8 Feb 2011 08:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYEbGfyWol6c for ; Tue, 8 Feb 2011 08:28:27 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id E8FED3A67A5 for ; Tue, 8 Feb 2011 08:28:26 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTVFvMYuHN7y15iwWsvc7xD/rEbeXQHV5@postini.com; Tue, 08 Feb 2011 08:28:34 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 21E7A1B83BC for ; Tue, 8 Feb 2011 08:28:33 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0383D190052; Tue, 8 Feb 2011 08:28:33 -0800 (PST) (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; Tue, 8 Feb 2011 08:28:32 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <6B3B9302-48C6-406A-BAFC-2AC62ABB29AF@apple.com> Date: Tue, 8 Feb 2011 11:28:28 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <653820E8-8DE1-43D5-AD27-DA08E70939E0@nominum.com> References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <6B3B9302-48C6-406A-BAFC-2AC62ABB29AF@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1082) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:28:28 -0000 On Feb 8, 2011, at 11:22 AM, james woodyatt wrote: > In this particular case, we can expect that happy-eyeballs = implementations will more often than not close unused connection = attempts in an orderly fashion, but hosts and networks get interrupted = all the time in the real world, and exceptions will be frequent. I = wouldn't want to be swimming against that tide. It sounds like you're saying CGN can't work. :) (Although, to be fair, I will reiterate that in the worst-case scenario = happy eyeballs as currently documented presents no more load to CGN than = non-happy-eyeballs, and in the usual case it presents less load.) From Fred.L.Templin@boeing.com Tue Feb 8 08:29:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDB3B3A67C0 for ; Tue, 8 Feb 2011 08:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.243 X-Spam-Level: X-Spam-Status: No, score=-6.243 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+B-Zlg+Q9DQ for ; Tue, 8 Feb 2011 08:29:31 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 1B7133A67E3 for ; Tue, 8 Feb 2011 08:29:30 -0800 (PST) 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 p18GTaHn016870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 10:29:36 -0600 (CST) 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 p18GTZ4F001726; Tue, 8 Feb 2011 08:29:35 -0800 (PST) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p18GTZC1001710 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 8 Feb 2011 08:29:35 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Tue, 8 Feb 2011 08:29:35 -0800 From: "Templin, Fred L" To: =?iso-8859-1?Q?Roger_J=F8rgensen?= , Randy Bush Date: Tue, 8 Feb 2011 08:29:34 -0800 Thread-Topic: [v6ops] Out of scope discussion [Fwd:I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] Thread-Index: AcvHWoSa/GNRIrVsR2OyC7GkAsbyMQAUln1g Message-ID: References: <4D4A2401.2020500@gmail.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: IPv6 Operations Subject: Re: [v6ops] Out of scope discussion [Fwd:I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:29:33 -0000 Hi Roger, > Fred, > What good will IRON bring? I provided a list of requirements several messages back: http://www.ietf.org/mail-archive/web/v6ops/current/msg07316.html The good that IRON brings is that it addresses each of these requirements (and more). Thanks - Fred fred.l.templin@boeing.com= From cb.list6@gmail.com Tue Feb 8 08:32:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E41923A67E3 for ; Tue, 8 Feb 2011 08:32:25 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIqx2kAm3PU5 for ; Tue, 8 Feb 2011 08:32:21 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id E453B3A67B8 for ; Tue, 8 Feb 2011 08:32:20 -0800 (PST) Received: by qyj19 with SMTP id 19so4523724qyj.10 for ; Tue, 08 Feb 2011 08:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SN3OeT0pGdCDiYxV+HWxteJbRRj+7RDZb6y1ZkCd2Eo=; b=AuX0OVin35GMvpVoRYlfbifJoO2hl9ssd7uG/RvcIrN/K5WMFoINSUzmL8gRfsX8cl KUv7FF89Bx9uyz93PtVcXFsLOApGQBInFvfqU7taMmHiZJ+lLAkUGp4yrNp+0lrjOBDv 7kxyW1kCDb0x0RsUESqZ4s3sRj5JyJW6mLaTg= 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=wAT3QggOsOuUW0ZLmC6gwRkMvNC434IIpr/ZYrgUc7CYCtq5XweX7x5VMU5O6cfa+j zLu0sNgEYBkP1VFNLf+Xmjp+EwAWaw9TJbpftqO3vTh0fVtRYcoTTdHM24+wL7Stls5f 4Un2unfTXZaCFjoCse/zcNYDwo9lfRaKX6t3Q= MIME-Version: 1.0 Received: by 10.229.96.83 with SMTP id g19mr13870412qcn.106.1297182747499; Tue, 08 Feb 2011 08:32:27 -0800 (PST) Received: by 10.229.224.79 with HTTP; Tue, 8 Feb 2011 08:32:27 -0800 (PST) In-Reply-To: <4D5162E4.1020606@redpill-linpro.com> References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@redpill-linpro.com> Date: Tue, 8 Feb 2011 08:32:27 -0800 Message-ID: From: Cameron Byrne To: Tore Anderson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:32:26 -0000 On Tue, Feb 8, 2011 at 7:36 AM, Tore Anderson wrote: > Hi, > > * Keith Moore > >> 6to4 is not harmful to IPv6 deployment. =A0ISPs that break IPv4 are >> harmful to IPv6 deployment. > > 6to4 was the major reason why I had to delay deploying AAAAs for the > sites I host. Instead of being able to deploy, I had to run around for > more than a year begging hardware and OS vendors to turn it off. > > So yes, 6to4 is very harmful to people wanting to deploy IPv6. Why do > you think =ABWorld IPv6 Day=BB is seen as necessary? > >>> 6to4 is what is distracting us. having to fix brokenness triggered >>> by 6to4. > > Precisely. > >> I think the statement in a nutshell is this: as long as operators >> insist on seeing 6to4 as a 'problem' rather than a way to provide >> their customers good service and a useful transition tool, they're >> going to keep sabotaging it. =A0By doing so they're actually impairing >> deployment of IPv6. > > Reverse 6to4 relays deployed close to the content? Check. > > That doesn't fix the problem, though. There's nothing I, or any other > individual network operator, can do to fix it. In order for 6to4 to work > reliably, *everyone* must play along. And that's simply not going to happ= en. > > 6to4 was a fun little toy for people who wanted to experiment with IPv6. > It is completely unsuitable to be Mr. John Q. Public's generic IPv6 > internet connectivity. At this point in time, *real* IPv6 deployments is > necessary, and 6to4 is just getting in the way. It's time to shelve it. > This is the conclusion i believe you will hear from all network operators that are really doing IPv6 now. I am not sure what it is about tunneled IPv6 access that makes their creators so adamant about it ... It's really native v4/v4v6/v6 or nothing on the real internet. Why? Because people don't care about IP versions, and a tunnel is never worth it. They care that facebook works. Everything else is just pedantry. Cameron From cb.list6@gmail.com Tue Feb 8 08:45:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA4D3A6768 for ; Tue, 8 Feb 2011 08:45:01 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pubPFtG4+liz for ; Tue, 8 Feb 2011 08:45:00 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 1E1A83A63D2 for ; Tue, 8 Feb 2011 08:44:59 -0800 (PST) Received: by qwi2 with SMTP id 2so4608602qwi.31 for ; Tue, 08 Feb 2011 08:45:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sJAFFRct//+h7ajJp60fK5c+f0cqYu13iW4pHysKfwg=; b=bfaBMQwwmRitHnOHo9TPGIwkHSC7BE7wMjhP3PmYP+A7j/h/vXZcNy1w1Gom24dNLZ Bzw5k10ptAHNANn6ZYbPwaO1qbIlCnhRBfZTC0uoVe13aGUeuhTZBi33pDPnOxqODwyr 1rHtbmlv2+rgrySxkwfSnLrdl2EDNtH7MOW4A= 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=qQWGOS75qe311QIKeTiQIhSm0jDPAAJL9k1EZtl0AmZJdnMazSUldGzlECGnwgIoor eKi+JMkGQGiZ89MNh0OXAHmHaSFN4zN3U2fPggQySwi6KSuagiSz5uEXreFuKebyjZ7n jnhdtW4bEO8dVzaKjoUucP4ORjIMbOGn5gzCI= MIME-Version: 1.0 Received: by 10.229.87.149 with SMTP id w21mr12141480qcl.68.1297183506679; Tue, 08 Feb 2011 08:45:06 -0800 (PST) Received: by 10.229.224.79 with HTTP; Tue, 8 Feb 2011 08:45:06 -0800 (PST) In-Reply-To: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> Date: Tue, 8 Feb 2011 08:45:06 -0800 Message-ID: From: Cameron Byrne To: Ole Troan Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:45:01 -0000 > > http://www.google.com/trends?q=disable+ipv6,+enable+ipv6 > (;-)) > http://readonly.labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really > > [...] For real network operators, these above links from Ole are the death knell for 6to4, and a strong call to support to make 6to4 historic so OS vendors will get the clue to turn it off by default for good. Short link just to make it real easy http://bit.ly/hl3w0n Cameron From Roman.Arcea@orange.md Tue Feb 8 08:47:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0873A67C0; Tue, 8 Feb 2011 08:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzxLYHeVANgL; Tue, 8 Feb 2011 08:47:44 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id 4781A3A67B8; Tue, 8 Feb 2011 08:47:41 -0800 (PST) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id 6487CB18004; Tue, 8 Feb 2011 18:47:41 +0200 (EET) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id 48CE9B18003; Tue, 8 Feb 2011 18:47:41 +0200 (EET) In-Reply-To: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@redpill-linpro.com> To: Cameron Byrne MIME-Version: 1.0 X-KeepSent: DC4D8861:F0BDF021-C2257831:005B34EB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Roman.Arcea@orange.md Date: Tue, 8 Feb 2011 18:47:40 +0200 X-MIMETrack: Serialize by Router on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 02/08/2011 18:47:39, Serialize complete at 02/08/2011 18:47:39 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Cc: v6ops-bounces@ietf.org, IPv6 Operations , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:47:45 -0000 v6ops-bounces@ietf.org wrote on 08-02-2011 18:32:27: > From: Cameron Byrne > To: Tore Anderson > Cc: IPv6 Operations , Keith Moore=20 > Date: 08-02-11 18:32 > Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan- > v6ops-6to4-to-historic-00 > Sent by: v6ops-bounces@ietf.org >=20 > On Tue, Feb 8, 2011 at 7:36 AM, Tore Anderson > wrote: > > Hi, > > > > * Keith Moore > > > >> 6to4 is not harmful to IPv6 deployment. ISPs that break IPv4 are > >> harmful to IPv6 deployment. > > > > 6to4 was the major reason why I had to delay deploying AAAAs for the > > sites I host. Instead of being able to deploy, I had to run around for > > more than a year begging hardware and OS vendors to turn it off. > > > > So yes, 6to4 is very harmful to people wanting to deploy IPv6. Why do > > you think =ABWorld IPv6 Day=BB is seen as necessary? > > > >>> 6to4 is what is distracting us. having to fix brokenness triggered > >>> by 6to4. > > > > Precisely. > > > >> I think the statement in a nutshell is this: as long as operators > >> insist on seeing 6to4 as a 'problem' rather than a way to provide > >> their customers good service and a useful transition tool, they're > >> going to keep sabotaging it. By doing so they're actually impairing > >> deployment of IPv6. > > > > Reverse 6to4 relays deployed close to the content? Check. > > > > That doesn't fix the problem, though. There's nothing I, or any other > > individual network operator, can do to fix it. In order for 6to4 to=20 work > > reliably, *everyone* must play along. And that's simply not going to=20 happen. > > > > 6to4 was a fun little toy for people who wanted to experiment with=20 IPv6. > > It is completely unsuitable to be Mr. John Q. Public's generic IPv6 > > internet connectivity. At this point in time, *real* IPv6 deployments=20 is > > necessary, and 6to4 is just getting in the way. It's time to shelve=20 it. > > > This is the conclusion i believe you will hear from all network > operators that are really doing IPv6 now. I am not sure what it is > about tunneled IPv6 access that makes their creators so adamant about > it ... It's really native v4/v4v6/v6 or nothing on the real internet. > Why? Because people don't care about IP versions, and a tunnel is > never worth it. They care that facebook works. Everything else is > just pedantry. +1 to what Tore and Cameron say I am running a private 6to4 relay for my customers only. This indeed makes = the service much better. However, as long as the return path is out of my=20 control, it is not near as good as the native IPv6 I have and is just a=20 hobby, not nearly a real service I can offer support for. And no, I don't=20 have the issues Cameron currently has with the address space, in which=20 situation 6to4 becomes the worst thing you could ever imagine. In a year=20 from now, the 6to4 will become a dead end. To be frank, as long as their is a solution that in any way stops the=20 content providers to serve AAAAs, it is bad. At this critical time, we=20 should not get distracted with any hacks. Forget tunneling, put time in=20 native IPv6, commit to content owners to have them doing it as well, and=20 as soon as a large part of Alexa 1M is on IPv6, the things will start=20 sorting themselves out. Best, Roman=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From moore@network-heretics.com Tue Feb 8 08:55:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C943A67E2 for ; Tue, 8 Feb 2011 08:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pe-dyNJpN6t8 for ; Tue, 8 Feb 2011 08:55:08 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 5AA2E3A679F for ; Tue, 8 Feb 2011 08:55:05 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmqqL-0006sD-FC; Tue, 08 Feb 2011 11:55:11 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: <4D5162E4.1020606@redpill-linpro.com> Date: Tue, 8 Feb 2011 11:55:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@redpill-linpro.com> To: Tore Anderson X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9401329080313608eced7ce5d9f0b607880350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:55:10 -0000 On Feb 8, 2011, at 10:36 AM, Tore Anderson wrote: > Hi, >=20 > * Keith Moore >=20 >> 6to4 is not harmful to IPv6 deployment. ISPs that break IPv4 are >> harmful to IPv6 deployment. >=20 > 6to4 was the major reason why I had to delay deploying AAAAs for the > sites I host. Instead of being able to deploy, I had to run around for > more than a year begging hardware and OS vendors to turn it off. >=20 > So yes, 6to4 is very harmful to people wanting to deploy IPv6. Why do > you think =ABWorld IPv6 Day=BB is seen as necessary? 6to4 wasn't the reason - the reason was broken IPv4 networks. But yes, = since 6to4 relies on IPv4 working, when the IPv4 network breaks, 6to4 = also breaks. The problem is caused by ISPs who act as if a few = applications (e.g. HTTP and SMTP) are the only ones that matter. >>> 6to4 is what is distracting us. having to fix brokenness triggered >>> by 6to4. >=20 > Precisely. 6to4 didn't trigger the brokenness; 6to4 merely exposed the brokenness. Still, I'll readily grant that if people's early experience of "IPv6" is = 6to4 over broken IPv4 networks, they'll have a poor impression of IPv6. =20= (If memory serves, I actually pointed this out to IESG over ten years = ago. It's not like this is a new problem, though the degree of IPv4 = brokenness has increased.) >> I think the statement in a nutshell is this: as long as operators >> insist on seeing 6to4 as a 'problem' rather than a way to provide >> their customers good service and a useful transition tool, they're >> going to keep sabotaging it. By doing so they're actually impairing >> deployment of IPv6. >=20 > Reverse 6to4 relays deployed close to the content? Check. >=20 > That doesn't fix the problem, though. There's nothing I, or any other > individual network operator, can do to fix it. In order for 6to4 to = work > reliably, *everyone* must play along. And that's simply not going to = happen. In order for IPv4 to work reliably, *everyone* must play along. If that = can't happen anymore, neither can IPv6 be made to work reliably. > 6to4 was a fun little toy for people who wanted to experiment with = IPv6. > It is completely unsuitable to be Mr. John Q. Public's generic IPv6 > internet connectivity. At this point in time, *real* IPv6 deployments = is > necessary, and 6to4 is just getting in the way. It's time to shelve = it. Meanwhile lots of people are getting real work done with 6to4, and = you're trying to sabotage their work in favor of a better solution that = doesn't exist yet. Keith From jhw@apple.com Tue Feb 8 09:00:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9023A67F1 for ; Tue, 8 Feb 2011 09:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o2XlMhAHyxC for ; Tue, 8 Feb 2011 09:00:38 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 9D2653A680E for ; Tue, 8 Feb 2011 09:00:33 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 236F8CD6D0F0 for ; Tue, 8 Feb 2011 09:00:41 -0800 (PST) X-AuditID: 1180711d-b7c12ae00000228a-c3-4d5176b838a8 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay13.apple.com (Apple SCV relay) with SMTP id 0C.E7.08842.8B6715D4; Tue, 8 Feb 2011 09:00:41 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from 67-218-103-233.cust.layer42.net (67-218-103-233.cust.layer42.net [67.218.103.233]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LGB00GT65X1RGA0@et.apple.com> for v6ops@ietf.org; Tue, 08 Feb 2011 09:00:40 -0800 (PST) From: james woodyatt In-reply-to: <4D5162E4.1020606@redpill-linpro.com> Date: Tue, 08 Feb 2011 09:00:36 -0800 Message-id: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@redpill-linpro.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:00:50 -0000 On Feb 8, 2011, at 07:36, Tore Anderson wrote: > > At this point in time, *real* IPv6 deployments is necessary, and 6to4 is just getting in the way. It's time to shelve it. Agreed. When it's all packed up and reposing gently on a shelf somewhere-- and *not* widely used on the public IPv4 anymore-- then I will agree that moving 6to4-anycast to Historic is proper use of IETF time. Not yet. Operators can make 6to4 go away according to its natural evolution by deploying native IPv6 service and following the recommendations in I-D.carpenter-v6ops-6to4-teredo-advisory. When 6to4 relays aren't needed anymore, then we should move RFC 3068 to Historic and let RFC 3056 ride off into the sunset with the rest of IPv4. -- james woodyatt member of technical staff, communications engineering From gert@space.net Tue Feb 8 09:02:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A413E3A679F for ; Tue, 8 Feb 2011 09:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Qv52H8fIVEa for ; Tue, 8 Feb 2011 09:02:23 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by core3.amsl.com (Postfix) with ESMTP id 2C49D3A67F9 for ; Tue, 8 Feb 2011 09:02:21 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 88462F81A3 for ; Tue, 8 Feb 2011 18:02:27 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 751DEF8179 for ; Tue, 8 Feb 2011 18:02:27 +0100 (CET) Received: (qmail 56588 invoked by uid 1007); 8 Feb 2011 18:02:27 +0100 Date: Tue, 8 Feb 2011 18:02:27 +0100 From: Gert Doering To: Keith Moore Message-ID: <20110208170227.GV44800@Space.Net> References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@redpill-linpro.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: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:02:23 -0000 Hi, On Tue, Feb 08, 2011 at 11:55:01AM -0500, Keith Moore wrote: > Meanwhile lots of people are getting real work done with 6to4, and you're trying to sabotage their work in favor of a better solution that doesn't exist yet. Nobody will take away your ability to run 6to4 on *your* devices, communicating between *your* endpoints in any matter you like. "Consenting adults", and such. It's just that for the large mass of people out there, the very existance of 6to4 is stopping content providers from enabling IPv6, and that's *bad*, so "6to4-on-by-default" for unsuspecting users needs to be stopped. Do what you want with your machines, but don't insist that your solution is any good for those that actually have researched the impact of 6to4 very thoroughly, like Tore did. Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From remi.despres@free.fr Tue Feb 8 09:02:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 528843A679F for ; Tue, 8 Feb 2011 09:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_20=-0.74, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhXpUlKfCWCv for ; Tue, 8 Feb 2011 09:02:23 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.21]) by core3.amsl.com (Postfix) with ESMTP id 7AC803A67E3 for ; Tue, 8 Feb 2011 09:02:22 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2311.sfr.fr (SMTP Server) with ESMTP id 237F47000081; Tue, 8 Feb 2011 18:02:29 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2311.sfr.fr (SMTP Server) with ESMTP id A9D4370000A6; Tue, 8 Feb 2011 18:02:28 +0100 (CET) X-SFR-UUID: 20110208170228695.A9D4370000A6@msfrf2311.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D505E87.8020706@gmail.com> Date: Tue, 8 Feb 2011 18:02:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9239FC42-51FC-4AD9-A63F-9002CB401AA0@free.fr> References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <3E3F1DEC-161F-42E1-9210-907F23F43A12@gmail.com> <4D4C565F.1010405@gmail.com> <4D4C6E39.4060200@brightok.net> <4D4C837F.8020306@gmail.com> <4D4FFAA9.2040306@brightok.net> <4D505345.8080006@gmail.com> <4D505E87.8020706@gmail.com> To: Randy Bush X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Out of scope discussion [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:02:24 -0000 Hi Randy, Le 7 f=E9vr. 2011 =E0 22:05, Brian E Carpenter a =E9crit : > On 2011-02-08 09:47, Randy Bush wrote: >> ... i want 6to4, teredo, 6rd, ... all dead dead dead. they are = damaging >> kludges to support pretend-v6 around lack of deployment...=20 >=20 > I think that's unfair on 6rd, which presents a genuine PA prefix to = the > IPv6 routing system. Indeed. I suppose you ignore that about half of the native IPv6 traffic Google = sees still comes from a single ISP, and that this ISP is that which has = been using 6rd as its way to offer IPv6 since 2007. Thus, suggesting that 6rd has limitations comparable to those of Teredo = and 6to4, while claiming to be in favor of IPv6 deployment, is a pure = contradiction. If I may, your reputation deserves better than that. Regards, RD From gert@space.net Tue Feb 8 09:04:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEFCB3A67E9 for ; Tue, 8 Feb 2011 09:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZkhQkbmUHqE for ; Tue, 8 Feb 2011 09:04:14 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by core3.amsl.com (Postfix) with ESMTP id 88B983A67E2 for ; Tue, 8 Feb 2011 09:04:14 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 37809F8189 for ; Tue, 8 Feb 2011 18:04:21 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 1B4CAF816A for ; Tue, 8 Feb 2011 18:04:21 +0100 (CET) Received: (qmail 56674 invoked by uid 1007); 8 Feb 2011 18:04:21 +0100 Date: Tue, 8 Feb 2011 18:04:21 +0100 From: Gert Doering To: james woodyatt Message-ID: <20110208170421.GW44800@Space.Net> References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@redpill-linpro.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: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:04:15 -0000 Hi, On Tue, Feb 08, 2011 at 09:00:36AM -0800, james woodyatt wrote: > On Feb 8, 2011, at 07:36, Tore Anderson wrote: > > > > At this point in time, *real* IPv6 deployments is necessary, and 6to4 is just getting in the way. It's time to shelve it. > > Agreed. When it's all packed up and reposing gently on a shelf somewhere-- and *not* widely used on the public IPv4 anymore-- then I will agree that moving 6to4-anycast to Historic is proper use of IETF time. Not yet. Well, what would you see as necessary to make vendors disable 6to4 in their default configuration? Apple already did, as far as I'm aware, and that's great :-) - so now we just need to convince the rest... Declaring 6to4 "historic" might just be the message to send to vendors. 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 Fred.L.Templin@boeing.com Tue Feb 8 09:12:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11D93A672E for ; Tue, 8 Feb 2011 09:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFpAamu0B5Iy for ; Tue, 8 Feb 2011 09:12:14 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 628CF3A63D3 for ; Tue, 8 Feb 2011 09:12:14 -0800 (PST) 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 p18HCD1W024767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 09:12:14 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p18HCDo0004387; Tue, 8 Feb 2011 09:12:13 -0800 (PST) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p18HCDuc004376 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 8 Feb 2011 09:12:13 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Tue, 8 Feb 2011 09:12:13 -0800 From: "Templin, Fred L" To: Keith Moore , Fred Baker Date: Tue, 8 Feb 2011 09:12:11 -0800 Thread-Topic: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 Thread-Index: AcvHU2I1pCn2WopbTxylqdEqKODlEQAXoWhg Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@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: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:12:15 -0000 Hi Keith, > Regarding IRON, I expect that it's biggest problem is that=20 > it's way behind on the deployment curve. That doesn't mean=20 > it's not worth considering of course, though one wonders how=20 > many of the myriad different possible transition mechanisms=20 > we need to implement. Minor correction - IRON is not intended as only a transition mechanism. IRON is tunnels-done-right, and there are many reasons why tunnels are desireable beyond just a fast-path to deployment of IPv6. About deployment, there is an initial implementation of IRON, and I am currently coding a v1.4 update: http://isatap.com/iron/iron-1.3.tgz I am not a full-time linux kernel networking software developer, but it should be easy for someone with those skills to see that there is no rocket science behind this. As I recall, the 6rd linux implementation went up in a matter of days. There is no reason the full-up IRON development profile could not progress along a similar timeline. Thanks - Fred fred.l.templin@boeing.com= From jhw@apple.com Tue Feb 8 09:14:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21623A67AD for ; Tue, 8 Feb 2011 09:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaUypH0aDGoT for ; Tue, 8 Feb 2011 09:14:48 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 36B413A63D3 for ; Tue, 8 Feb 2011 09:14:48 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 994F7D0C8C35 for ; Tue, 8 Feb 2011 09:14:55 -0800 (PST) X-AuditID: 11807130-b7b3cae00000405d-f1-4d517a0fd517 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay11.apple.com (Apple SCV relay) with SMTP id 5D.EC.16477.F0A715D4; Tue, 8 Feb 2011 09:14:55 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from 67-218-103-233.cust.layer42.net (67-218-103-233.cust.layer42.net [67.218.103.233]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LGB00G506KQRGB0@et.apple.com> for v6ops@ietf.org; Tue, 08 Feb 2011 09:14:55 -0800 (PST) From: james woodyatt In-reply-to: <20110208170421.GW44800@Space.Net> Date: Tue, 08 Feb 2011 09:14:50 -0800 Message-id: <0EDB086A-1760-4BBF-93FA-38B60855DCE0@apple.com> References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@redpill-linpro.com> <20110208170421.GW44800@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:14:49 -0000 On Feb 8, 2011, at 09:04, Gert Doering wrote: > > Declaring 6to4 "historic" might just be the message to send to vendors. Equipment makers that are still enabling 6to4 by default are unlikely to notice that IETF has published an RFC that moves 6to4 to Historic status. I think World IPv6 Day will cut through the noise a lot better than this draft ever will. -- james woodyatt member of technical staff, communications engineering From moore@network-heretics.com Tue Feb 8 09:16:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C604B3A67C0 for ; Tue, 8 Feb 2011 09:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnN3SMLob4bW for ; Tue, 8 Feb 2011 09:16:55 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id D6B153A67AD for ; Tue, 8 Feb 2011 09:16:54 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmrBT-0004kz-DA; Tue, 08 Feb 2011 12:17:00 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110208170227.GV44800@Space.Net> Date: Tue, 8 Feb 2011 12:16:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@redpill-linpro.com> <20110208170227.GV44800@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940b1b693517fd50a1ccfb02ebf08f58bb7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:16:55 -0000 On Feb 8, 2011, at 12:02 PM, Gert Doering wrote: > Hi, >=20 > On Tue, Feb 08, 2011 at 11:55:01AM -0500, Keith Moore wrote: >> Meanwhile lots of people are getting real work done with 6to4, and = you're trying to sabotage their work in favor of a better solution that = doesn't exist yet. >=20 > Nobody will take away your ability to run 6to4 on *your* devices, = communicating between *your* endpoints in any matter you like. =20 Not clear. People are talking about blocking protocol 41, for example. > "Consenting adults", and such. >=20 > It's just that for the large mass of people out there, the very = existance > of 6to4 is stopping content providers from enabling IPv6, and that's = *bad*, > so "6to4-on-by-default" for unsuspecting users needs to be stopped. This is a misstatement of the problem. It's not the existence of 6to4 = that's stopping content providers from enabling v6. It's broken = networks and relay routers that are stopping content providers from = enabling v6. That said, I'm all for having a push to implement something better if we = can get consensus among operators to do that. Just don't break 6to4 = until there's a widely available alternative that doesn't require = explicit user setup. > Do what you want with your machines, but don't insist that your = solution > is any good for those that actually have researched the impact of 6to4 > very thoroughly, like Tore did. I've been using 6to4 ever since the RFC was published. (I believe in = eating my own dog food.) I have observed firsthand every anomaly = documented in Brian's draft. And yet, somehow, 6to4 still works for me = and my customers most of the time. Keith From moore@network-heretics.com Tue Feb 8 09:17:07 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8EE53A67F3 for ; Tue, 8 Feb 2011 09:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jV1m533gcOKf for ; Tue, 8 Feb 2011 09:17:06 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id A76653A67FD for ; Tue, 8 Feb 2011 09:17:06 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmrBY-0004kz-OB; Tue, 08 Feb 2011 12:17:05 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D516522.9050007@brightok.net> Date: Tue, 8 Feb 2011 12:17:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4BF9DA98-DBD9-4658-A28A-C1463B3808C1@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> <4D515EE7.1080008@brightok.net> <4D516522.9050007@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940b1b693517fd50a1c249de3a2a68b094c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:17:07 -0000 On Feb 8, 2011, at 10:45 AM, Jack Bates wrote: > On 2/8/2011 9:40 AM, Ted Lemon wrote: >> I'm not following your argument here. Presumably if you get a AAAA, >> and you have v6 connectivity, you will connect successfully. If you >> get an A and an AAAA, you will still connect successfully. And if >> you get an A, you *might* connect successfully, if the LSN isn't >> overloaded, and if the NAT doesn't break something simply because it >> modified the packets in transit. Where's the case where adding >> working v6 makes things worse? >>=20 >=20 > Grandma goes to some website that has AAAA advertised and their IPv6 = address isn't on my Internet. >=20 > Grandma hits a DNS load balancer that responds to AAAA with nxdomain. >=20 > For every customer I turn up on IPv6, I find more brokenness. Well, sure. There are lots of things in the net, like interception = proxies, that are IPv6 naive. =20 Of course, this should serve as a lesson: don't put those things into = the network! They don't belong there. *Anything* that intercepts = traffic and tries to interpret it on behalf of its destination has a = good chance of biting you back someday. But sadly, instead of those things being removed, what will probably = have to happen is that those things get chased down and "fixed", one by = one. Just like anycast relays. Again, it's not reasonable to blame IPv6 or 6to4 because they happen to = explore brokenness that already exists in the IPv4 network. The blame = lies squarely with the operators and equipment vendors. Keith From moore@network-heretics.com Tue Feb 8 09:19:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90893A67F3 for ; Tue, 8 Feb 2011 09:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuIErrOAzg-z for ; Tue, 8 Feb 2011 09:19:03 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 255E63A67E2 for ; Tue, 8 Feb 2011 09:19:03 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmrDX-0003vR-85; Tue, 08 Feb 2011 12:19:08 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Tue, 8 Feb 2011 12:18:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2B99A9A3-3FD5-42E2-B4A9-B7262737B80A@network-heretics.com> References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@redpill-linpro.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940998123fc709e5fd5c5ea4563f5bd7a9c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:19:04 -0000 On Feb 8, 2011, at 11:32 AM, Cameron Byrne wrote: >> veryone* must play along. And that's simply not going to happen. >>=20 >> 6to4 was a fun little toy for people who wanted to experiment with = IPv6. >> It is completely unsuitable to be Mr. John Q. Public's generic IPv6 >> internet connectivity. At this point in time, *real* IPv6 deployments = is >> necessary, and 6to4 is just getting in the way. It's time to shelve = it. >>=20 >=20 > This is the conclusion i believe you will hear from all network > operators that are really doing IPv6 now. I am not sure what it is > about tunneled IPv6 access that makes their creators so adamant about > it ... It's really native v4/v4v6/v6 or nothing on the real internet. > Why? Because people don't care about IP versions, and a tunnel is > never worth it. They care that facebook works. Everything else is > just pedantry. That is of course, completely false. And operators who persist in = believing that are the source of the problem.=20 Keith From remi.despres@free.fr Tue Feb 8 09:21:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB483A6803 for ; Tue, 8 Feb 2011 09:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x36w856BnXrZ for ; Tue, 8 Feb 2011 09:21:40 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.21]) by core3.amsl.com (Postfix) with ESMTP id A36D13A67F3 for ; Tue, 8 Feb 2011 09:21:40 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2311.sfr.fr (SMTP Server) with ESMTP id A46D8700009F; Tue, 8 Feb 2011 18:21:47 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2311.sfr.fr (SMTP Server) with ESMTP id 369C27000081; Tue, 8 Feb 2011 18:21:47 +0100 (CET) X-SFR-UUID: 20110208172147223.369C27000081@msfrf2311.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D506357.5060709@gmail.com> Date: Tue, 8 Feb 2011 18:21:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4A2401.2020500@gmail.com> <7474B6BC-EC21-447A-B2F4-1CB666E0ABA1@employees.org> <92404332-3EEC-4FB6-A6A4-319F6970B447@steffann.nl> <4D4ACEFA.3080106@brightok.net> <7089BBFC-87B6-491F-A9B1-0EE38B0BF353@steffann.nl> <6FC549CF-C1C5-474D-BB55-9E4C406E1B15@network-heretics.com> <4D4C2EAC.2030509@brightok.net> <4905BDD3-DE25-4CE9-854D-7673705DF74E@free.fr> <4D4C3E51.8070503@brightok.net> <8469C978-D60E-45AD-A534-A8E989DB8374@free.fr> <4D500BB0.70103@redpill-linpro.com> <4D506357.5060709@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:21:41 -0000 Le 7 f=E9vr. 2011 =E0 22:25, Brian E Carpenter a =E9crit : > On 2011-02-08 04:11, Tore Anderson wrote: >> * R=E9mi Despr=E9s >>=20 >>> Thus, a server that advertises a native IPv6 address AND an 6to4 >>> address becomes reachable by 6to4 clients even if they have no = access >>> to 6to4 relays. >>> Reachability is thus increased, and I haven't found any adverse >>> effect. >>> Do you see any? >>=20 >> I actually attempted this a while back. It was a disaster and the >> brokenness percentage skyrocketed. I don't think any content = providers >> in their right mind will publish AAAA-records for a 2002::/16 = address. >=20 > I will definitely add advice against that in the draft. The point of Tore is well made, so that, for large content providers, I = now agree. OTOH, the advice should be softened for small servers that are in sites = in where CPEs have 6to4 prefixes and no native IPv6 prefix.=20 I believe Keith also made this point. Regards, RD From moore@network-heretics.com Tue Feb 8 09:33:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB743A67EC for ; Tue, 8 Feb 2011 09:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgYaVYAoufH4 for ; Tue, 8 Feb 2011 09:33:01 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 654C73A672E for ; Tue, 8 Feb 2011 09:33:01 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmrQx-00023J-25; Tue, 08 Feb 2011 12:33:02 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Tue, 8 Feb 2011 12:32:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> To: Ole Troan X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9403d751aaa5817e7935a87201f67f1f828350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:33:04 -0000 On Feb 8, 2011, at 11:00 AM, Ole Troan wrote: > Keith, >=20 >>> 6to4 model 1 is not (and has never been) deployed (basically = recreates the 6bone). >>=20 >> Incorrect on both counts. >=20 > examples please. I don't know how to give you examples. But 6to4 never has been like the = 6bone in any way other than using IP tunneling. >>> 6to4 model 2, even with a consenting forward relay suffers the same = issues on the reverse path. >>> in my view 6to4 is not salvageable.=20 >>=20 >> Perhaps that's because you haven't tried to identify solutions? it = is possible, for instance, to identify and marginalize broken relay = routers. >=20 > how? > the problem with relays routers are that they depend on charity by 3rd = parties. No more than the Internet depends on charity by 3rd parties to route = traffic. > it is difficult to see the motivation for anyone to run a relay router = in the first place. To provide better service to their customers? Nah, no provider would = want to do that... > if I thought 6to4 could be fixed I would have suggested the fixes. you = seem so convinced that there are fixes, can you please share those? Best fix I see offhand is for operators to a) implement correctly working relay routers, and/or b) actively test whether any relay routers advertised from their peers = work properly, and if not, filter their advertisements I'm sure this can be improved on, but this is a start. >> 6to4 provides a way for anyone with any properly working IPv4 connect = to connect to any IPv6 host. That's a huge win. It eliminates one of = the barriers toward IPv6 acceptance by providing a means for universal = access to IPv6 over any properly working IPv4 connection. >=20 > unfortunately that's not the end-user experience that has been shown. >=20 > http://www.google.com/trends?q=3Ddisable+ipv6,+enable+ipv6 > (;-)) > = http://readonly.labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really >=20 > [...] >=20 >> No, 6to4 is not broken. 6to4 is just sending IP packets and = expecting them to get to the hosts associated with their destination = addresses intact. >>=20 >> The network is broken because of many brain damaged practices in = place for other reasons, and 6to4 is one of many things suffering = because of it. =20 >>=20 >> (I sometimes suspect that 6to4 is also suffering because some = operators see it as an end-run around them, so they don't mind = implementing measures that penalize it. But that's not a problem with = 6to4....) >=20 > I have seen no evidence that operators are actively blocking 6to4. > 6to4 depends on the charity of others. unfortunately that's not a = realistic deployment model. That's also what they said about IP, once upon a time.=20 >>>> Note that I am *not* trying to unnaturally prolong the life of 6to4 = or >>>> Anycast 6to4. A good way to get rid of them is for all ISPs to = deploy IPv6, >>>> for example. >>>=20 >>> and until that happens (SP deploys IPv6), IPv6 deployment will not = happen. 6to4 does not in any way accelerate IPv6 deployment. >>=20 >> Completely incorrect. See above. >>=20 >> I think the statement in a nutshell is this: as long as operators = insist on seeing 6to4 as a 'problem' rather than a way to provide their = customers good service and a useful transition tool, they're going to = keep sabotaging it. By doing so they're actually impairing deployment = of IPv6. >=20 > I have seen no evidence of sabotage. Blocking proto 41 is an example of sabotage. Blocking traffic to relay = routers is an example of sabotage. Imposing DNS interception proxies = that return NXDOMAIN in response to AAAA queries is an example of = sabotage. Blocking ICMP messages is an example of sabotage. There are = several others. None of these solutions would ever have been remotely considered = acceptable had ISPs been doing their jobs in the first place - which is = to route packets intact to their destinations. > all the brokenness I have seen have been caused by "this is how the = 6to4/Internet works". your nearest relay is on a different continent, = one of the relays on the path are overloaded, ICMP messages are = blackholed, ICMP messages are blocked, bogus addresses are used, the = 6to4 relay is behind some Enterprise firewall... and so on... >=20 > I just don't understand how we can get the whole IPv4 Internet fixed, = plus get 6to4 deployed with relays in such a fashion that it works on = reasonably equal terms with IPv4. Ironically, if you could fix the v4 Internet, 6to4 would work just fine. = But you can't fix the v4 Internet. So what you have to do is try to = hold it together long enough to get native v6 deployed and get the bugs = worked out of it. > as you appear to have very strong opinions that 6to4 has a right of = life... can you please explain how we can make it a successful protocol. = where successful is almost equal to deployable. I think 6to4 needs to be on life support until we can arrange for a = transplant to native v6. Operators need to stop treating 6to4 as a = problem, and start treating it as something that their customers need = and have a right to expect. If they want to stop supporting it ASAP, = they have my complete encouragement to do so as soon as something that's = clearly better is widely available. Keith From moore@network-heretics.com Tue Feb 8 09:37:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579F63A6814 for ; Tue, 8 Feb 2011 09:37:34 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j5NSkixGfM8 for ; Tue, 8 Feb 2011 09:37:33 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 0D27B3A680D for ; Tue, 8 Feb 2011 09:37:33 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmrVS-00087g-QN; Tue, 08 Feb 2011 12:37:39 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Tue, 8 Feb 2011 12:37:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9404741394b180688eafd2c6139e5b79588350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:37:34 -0000 On Feb 8, 2011, at 12:12 PM, Templin, Fred L wrote: > Hi Keith, >=20 >> Regarding IRON, I expect that it's biggest problem is that=20 >> it's way behind on the deployment curve. That doesn't mean=20 >> it's not worth considering of course, though one wonders how=20 >> many of the myriad different possible transition mechanisms=20 >> we need to implement. >=20 > Minor correction - IRON is not intended as only a transition > mechanism. IRON is tunnels-done-right, and there are many > reasons why tunnels are desireable beyond just a fast-path > to deployment of IPv6. >=20 > About deployment, there is an initial implementation of > IRON, and I am currently coding a v1.4 update: >=20 > http://isatap.com/iron/iron-1.3.tgz >=20 > I am not a full-time linux kernel networking software > developer, but it should be easy for someone with those > skills to see that there is no rocket science behind > this. As I recall, the 6rd linux implementation went up > in a matter of days. There is no reason the full-up IRON > development profile could not progress along a similar > timeline. >=20 > Thanks - Fred > fred.l.templin@boeing.com 6to4 support has shipped with Windows, *BSD, MacOS, Linux for several = years now. Even if IRON is the best thing since sliced bread, I don't = see how it can compete with that any time soon. It takes time for = people to upgrade their OSes. I don't want to discourage a potentially good long-term solution for = using IPv6 in overlay networks...but realistically I don't think IRON = can replace 6to4 before 6to4 reaches its natural EOL, which I hope is = within 2-4 years. Keith From remi.despres@free.fr Tue Feb 8 09:43:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5DA03A680B for ; Tue, 8 Feb 2011 09:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_40=-0.185, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT3bVdVesJnc for ; Tue, 8 Feb 2011 09:43:57 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by core3.amsl.com (Postfix) with ESMTP id EDD593A67AD for ; Tue, 8 Feb 2011 09:43:56 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2402.sfr.fr (SMTP Server) with ESMTP id 9E15870000A4; Tue, 8 Feb 2011 18:44:03 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2402.sfr.fr (SMTP Server) with ESMTP id E47227000098; Tue, 8 Feb 2011 18:44:02 +0100 (CET) X-SFR-UUID: 20110208174402935.E47227000098@msfrf2402.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 8 Feb 2011 18:44:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> To: Brian Carpenter X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:43:57 -0000 Brian, I find Ole's proposal interesting *for the new phase we are entering*, = i.e. one where: - native IPv6 adresses are progressively deployed - 6to4, that has been extensively use despite its limitations, should = now recede =20 Le 8 f=E9vr. 2011 =E0 10:14, Ole Troan a =E9crit : > ... 6to4 does not in any way accelerate IPv6 deployment. >=20 > if the draft can achieve that: > - CPE and hosts vendors stop enabling 6to4 by default +1=20 > - no-one advertises 6to4 AAAA records in DNS Except maybe where 6to4 is the only available incoming connectivity, but = that's minor. > - 6to4 is put at the absolute bottom (with Teredo) in the SAS/DAS = algorithms. Ideally, RFC 3484bis would do it. > - people stop considering 6to4 as a valid transitioning mechanism; = there are too many choices already. At least not a mechanism to be considered for new deployments. Regards, RD =20= From Fred.L.Templin@boeing.com Tue Feb 8 09:44:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA46D3A67E7 for ; Tue, 8 Feb 2011 09:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgoWuo2EGZqM for ; Tue, 8 Feb 2011 09:44:27 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 1173E3A681E for ; Tue, 8 Feb 2011 09:44:23 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p18HiPFi007333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 09:44:25 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p18HiPbQ006297; Tue, 8 Feb 2011 09:44:25 -0800 (PST) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p18HiOCY006288 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 8 Feb 2011 09:44:25 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Tue, 8 Feb 2011 09:44:25 -0800 From: "Templin, Fred L" To: Keith Moore Date: Tue, 8 Feb 2011 09:44:23 -0800 Thread-Topic: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 Thread-Index: AcvHtvR4mlP3lLQNQ/m/jfLfEh5XZAAACaJg Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@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: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:44:29 -0000 Hi Keith,=20 > -----Original Message----- > From: Keith Moore [mailto:moore@network-heretics.com]=20 > Sent: Tuesday, February 08, 2011 9:38 AM > To: Templin, Fred L > Cc: Fred Baker; IPv6 Operations > Subject: Re: [v6ops] Fwd: New Version Notificationfor=20 > draft-troan-v6ops-6to4-to-historic-00 >=20 > On Feb 8, 2011, at 12:12 PM, Templin, Fred L wrote: >=20 > > Hi Keith, > >=20 > >> Regarding IRON, I expect that it's biggest problem is that=20 > >> it's way behind on the deployment curve. That doesn't mean=20 > >> it's not worth considering of course, though one wonders how=20 > >> many of the myriad different possible transition mechanisms=20 > >> we need to implement. > >=20 > > Minor correction - IRON is not intended as only a transition > > mechanism. IRON is tunnels-done-right, and there are many > > reasons why tunnels are desireable beyond just a fast-path > > to deployment of IPv6. > >=20 > > About deployment, there is an initial implementation of > > IRON, and I am currently coding a v1.4 update: > >=20 > > http://isatap.com/iron/iron-1.3.tgz > >=20 > > I am not a full-time linux kernel networking software > > developer, but it should be easy for someone with those > > skills to see that there is no rocket science behind > > this. As I recall, the 6rd linux implementation went up > > in a matter of days. There is no reason the full-up IRON > > development profile could not progress along a similar > > timeline. > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com >=20 >=20 > 6to4 support has shipped with Windows, *BSD, MacOS, Linux for=20 > several years now. Even if IRON is the best thing since=20 > sliced bread, I don't see how it can compete with that any=20 > time soon. It takes time for people to upgrade their OSes. Sure, ISATAP is there in wide deployment too. But, in the case of IRON it is not necessary that all nor even most platforms support it. All it needs is for one or a few platforms within an IRON End User Network (EUN) to implement the IRON client function, and then all other devices within the EUN get to use native IPv6! (Or ISATAP if they have no other choice.) So, that means that IRON would only have to touch one or a couple of popular platforms in order to enable widespread deployment. And, linux seems like a good place to start... Thanks - Fred fred.l.templin@boeing.com =20 > I don't want to discourage a potentially good long-term=20 > solution for using IPv6 in overlay networks...but=20 > realistically I don't think IRON can replace 6to4 before 6to4=20 > reaches its natural EOL, which I hope is within 2-4 years. >=20 > Keith >=20 > = From moore@network-heretics.com Tue Feb 8 09:47:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7943A67D2 for ; Tue, 8 Feb 2011 09:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-V7aPvv4CYQ for ; Tue, 8 Feb 2011 09:47:18 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 9B6703A679F for ; Tue, 8 Feb 2011 09:47:18 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmreV-0006bb-CR; Tue, 08 Feb 2011 12:47:00 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-39-1052436192 From: Keith Moore In-Reply-To: Date: Tue, 8 Feb 2011 12:46:55 -0500 Message-Id: <8BB85FD2-408B-424E-835A-7991EA3B3DE2@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9403c6e856f7704b8d2dbddef9105af897a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:47:19 -0000 --Apple-Mail-39-1052436192 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 8, 2011, at 12:44 PM, Templin, Fred L wrote: >>=20 >>=20 >> 6to4 support has shipped with Windows, *BSD, MacOS, Linux for=20 >> several years now. Even if IRON is the best thing since=20 >> sliced bread, I don't see how it can compete with that any=20 >> time soon. It takes time for people to upgrade their OSes. >=20 > Sure, ISATAP is there in wide deployment too. But, in > the case of IRON it is not necessary that all nor even > most platforms support it. All it needs is for one or > a few platforms within an IRON End User Network (EUN) > to implement the IRON client function, and then all > other devices within the EUN get to use native IPv6! > (Or ISATAP if they have no other choice.) >=20 > So, that means that IRON would only have to touch one > or a couple of popular platforms in order to enable > widespread deployment. And, linux seems like a good > place to start... that's great for corner cases, but it doesn't make for a general = solution. at least, not in the short term. Keith --Apple-Mail-39-1052436192 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


6to4 support = has shipped with Windows, *BSD, MacOS, Linux for =
several years now. =   Even if IRON is the best thing since =
sliced bread, I don't see how = it can compete with that any
time soon.  It takes time for people to upgrade their = OSes.

Sure, ISATAP is there in wide deployment too. = But, in
the case of IRON it is not necessary that all nor = even
most platforms support it. All it needs is for one or
a few = platforms within an IRON End User Network (EUN)
to implement the IRON = client function, and then all
other devices within the EUN get to use = native IPv6!
(Or ISATAP if they have no other choice.)

So, = that means that IRON would only have to touch one
or a couple of = popular platforms in order to enable
widespread deployment. And, = linux seems like a good
place to = start...

that's great for corner cases, = but it doesn't make for a general solution.  at least, not in the = short = term.

Keith

= --Apple-Mail-39-1052436192-- From jbates@brightok.net Tue Feb 8 09:50:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60E2E3A6816 for ; Tue, 8 Feb 2011 09:50:00 -0800 (PST) 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.049, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEY+DMzpbfy1 for ; Tue, 8 Feb 2011 09:49:59 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 875903A67EB for ; Tue, 8 Feb 2011 09:49:59 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18Ho1ff015358; Tue, 8 Feb 2011 11:50:01 -0600 (CST) Message-ID: <4D518248.3000900@brightok.net> Date: Tue, 08 Feb 2011 11:50:00 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> <4D515EE7.1080008@brightok.net> <4D516522.9050007@brightok.net> <4BF9DA98-DBD9-4658-A28A-C1463B3808C1@network-heretics.com> In-Reply-To: <4BF9DA98-DBD9-4658-A28A-C1463B3808C1@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:50:00 -0000 On 2/8/2011 11:17 AM, Keith Moore wrote: > On Feb 8, 2011, at 10:45 AM, Jack Bates wrote: > >> On 2/8/2011 9:40 AM, Ted Lemon wrote: >>> I'm not following your argument here. Presumably if you get a >>> AAAA, and you have v6 connectivity, you will connect >>> successfully. If you get an A and an AAAA, you will still >>> connect successfully. And if you get an A, you *might* connect >>> successfully, if the LSN isn't overloaded, and if the NAT doesn't >>> break something simply because it modified the packets in >>> transit. Where's the case where adding working v6 makes things >>> worse? >>> >> >> Grandma goes to some website that has AAAA advertised and their >> IPv6 address isn't on my Internet. >> >> Grandma hits a DNS load balancer that responds to AAAA with >> nxdomain. >> >> For every customer I turn up on IPv6, I find more brokenness. > > Well, sure. There are lots of things in the net, like interception > proxies, that are IPv6 naive. > I think you missed my point. 1) There are isolations in the core network. Baking cakes hasn't fixed them yet. 2) There are DNS servers which nxdomain AAAA records (which means fallback to A isn't an option). This has nothing to do with things in the middle that are intercepting and causing havoc (doesn't matter if the DNS is answered by a load balancer or an auth server, if it responds poorly to AAAA, it fails). > Again, it's not reasonable to blame IPv6 or 6to4 because they happen > to explore brokenness that already exists in the IPv4 network. The > blame lies squarely with the operators and equipment vendors. The IPv6 network is broken until core networks fix pathing and peering issues. End of story. Until that occurs, putting average joe on IPv6 is asking them to have a horrible experience. Jack From Fred.L.Templin@boeing.com Tue Feb 8 09:52:46 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A656F3A672E for ; Tue, 8 Feb 2011 09:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.812 X-Spam-Level: X-Spam-Status: No, score=-5.812 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THoCD+j6HjLw for ; Tue, 8 Feb 2011 09:52:45 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id A9F7E3A66B4 for ; Tue, 8 Feb 2011 09:52:45 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p18Hq8HF022087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 09:52:08 -0800 (PST) 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 p18Hq8j2010242; Tue, 8 Feb 2011 09:52:08 -0800 (PST) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p18Hq7Y1010215 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 8 Feb 2011 09:52:07 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Tue, 8 Feb 2011 09:52:07 -0800 From: "Templin, Fred L" To: Keith Moore Date: Tue, 8 Feb 2011 09:52:05 -0800 Thread-Topic: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 Thread-Index: AcvHuFbjwpO8i0H+R6GlSlmv5rJGBgAACJoQ Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <8BB85FD2-408B-424E-835A-7991EA3B3DE2@network-heretics.com> In-Reply-To: <8BB85FD2-408B-424E-835A-7991EA3B3DE2@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_E1829B60731D1740BB7A0626B4FAF0A65C6839FE22XCHNW01Vnwnos_" MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:52:46 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A65C6839FE22XCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Keith, > that's great for corner cases, but it doesn't make for a general solution= . at least, not in the short term. Not at all. For the price of a small S/W engineering investment, an IRON service provider can offer a downloadable module for an existing Windows, *BSD, MacOS, etc. platform as part of the arrangement with the customer. It is then just a point-and-click operation away, and the customer's EUN is up and running. Thanks - Fred fred.l.templin@boeing.com ________________________________ From: Keith Moore [mailto:moore@network-heretics.com] Sent: Tuesday, February 08, 2011 9:47 AM To: Templin, Fred L Cc: Fred Baker; IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to= 4-to-historic-00 On Feb 8, 2011, at 12:44 PM, Templin, Fred L wrote: 6to4 support has shipped with Windows, *BSD, MacOS, Linux for several years now. Even if IRON is the best thing since sliced bread, I don't see how it can compete with that any time soon. It takes time for people to upgrade their OSes. Sure, ISATAP is there in wide deployment too. But, in the case of IRON it is not necessary that all nor even most platforms support it. All it needs is for one or a few platforms within an IRON End User Network (EUN) to implement the IRON client function, and then all other devices within the EUN get to use native IPv6! (Or ISATAP if they have no other choice.) So, that means that IRON would only have to touch one or a couple of popular platforms in order to enable widespread deployment. And, linux seems like a good place to start... that's great for corner cases, but it doesn't make for a general solution. = at least, not in the short term. Keith --_000_E1829B60731D1740BB7A0626B4FAF0A65C6839FE22XCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Keith,
 
> that's great for corner cases, but i= t=20 doesn't make for a general solution.  at least, not in the short=20 term.
 
Not at=20 all. For the price of a small S/W engineering investment, an<= /DIV>
IRON=20 service provider can offer a downloadable module for an=20 existing
Windows, *BSD, MacOS, etc. platform as part of t= he=20 arrangement
with=20 the customer. It is then just a point-and-click operation=20 away,
and=20 the customer's EUN is up and running.
 
Thanks=20 - Fred
fred.l.templin@boeing.com

From: Keith Moore=20 [mailto:moore@network-heretics.com]
Sent: Tuesday, February 08= ,=20 2011 9:47 AM
To: Templin, Fred L
Cc: Fred Baker; IPv6= =20 Operations
Subject: Re: [v6ops] Fwd: New Version Notificationfo= r=20 draft-troan-v6ops-6to4-to-historic-00

On Feb 8, 2011, at 12:44 PM, Templin, Fred L wrote:


6to4 support has shipped with Windows, *BSD,= =20 MacOS, Linux for
several years now.   Even if IRON i= s the=20 best thing since
sliced bread, I don't see how it can compete = with=20 that any
time soon.  It takes time for people to= =20 upgrade their OSes.

Sure, ISATAP is there in wide= =20 deployment too. But, in
the case of IRON it is not necessary that al= l nor=20 even
most platforms support it. All it needs is for one or
a few= =20 platforms within an IRON End User Network (EUN)
to implement the IRO= N=20 client function, and then all
other devices within the EUN get to us= e=20 native IPv6!
(Or ISATAP if they have no other choice.)

So, th= at=20 means that IRON would only have to touch one
or a couple of popular= =20 platforms in order to enable
widespread deployment. And, linux seems= like=20 a good
place to start...

that's great for corner cases, but it doesn't make for a general=20 solution.  at least, not in the short term.

Keith

--_000_E1829B60731D1740BB7A0626B4FAF0A65C6839FE22XCHNW01Vnwnos_-- From moore@network-heretics.com Tue Feb 8 09:53:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6AB73A679F for ; Tue, 8 Feb 2011 09:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkgB9TcmTNmI for ; Tue, 8 Feb 2011 09:53:55 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id F21453A66B4 for ; Tue, 8 Feb 2011 09:53:54 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmrlI-0001ED-LU; Tue, 08 Feb 2011 12:54:02 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Tue, 8 Feb 2011 12:53:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2AD4DD41-50F9-4837-A33D-4E725323AA56@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <4D514EAB.3070109@brightok.net> <0BDAB499-AAE2-432B-B7C7-C2F03744FC93@network-heretics.com> To: Ted Lemon X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9406e139594b33d43ea869bec65208a010a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:53:55 -0000 On Feb 8, 2011, at 9:17 AM, Ted Lemon wrote: > On Feb 8, 2011, at 9:11 AM, Keith Moore wrote: >> unfortunately, it might end up killing v6 also. >=20 > It seems to me that the premise behind this assertion is that you = think that killing 6to4 will kill IPv6. It makes sense that you want = 6to4 for your particular application, but it doesn't make sense to say = that killing 6to4 will kill IPv6. I don't think it adds to the = discussion to overdramatize. I don't think it's being overdramatic. The reason that I think that = CGN is a threat to IPv6, and also the reason that I think 6to4 is fairly = essential, is that people don't just need to access the Internet from = one place. They need to be able to get to it from anywhere, using what = ever service is available where they happen to be. So they really need = a v6 access solution that works from anywhere and doesn't require much = if any explicit configuration. That solution doesn't inherently have to be 6to4, of course. But other = than native v6, 6to4 is by far the solution that is most widely = deployed. Any other solution could require several years to catch up. So I think there's a huge benefit in leveraging the 6to4 support that = already exists in most hosts. But hey, native v6 is even better. Keith From remi.despres@free.fr Tue Feb 8 09:56:30 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9C333A679F for ; Tue, 8 Feb 2011 09:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_40=-0.185, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pz35gCCedeHb for ; Tue, 8 Feb 2011 09:56:30 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by core3.amsl.com (Postfix) with ESMTP id 085F03A672E for ; Tue, 8 Feb 2011 09:56:30 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id 033A770000B5; Tue, 8 Feb 2011 18:56:37 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id 57C95700009D; Tue, 8 Feb 2011 18:56:34 +0100 (CET) X-SFR-UUID: 20110208175634359.57C95700009D@msfrf2221.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <1C37F0A2-88C6-4CB3-B624-608E0B7364F1@network-heretics.com> Date: Tue, 8 Feb 2011 18:56:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <20110208073126.GA18776@srv03.cluenet.de> <1C37F0A2-88C6-4CB3-B624-608E0B7364F1@network-heretics.com> To: Daniel Roesen X-Mailer: Apple Mail (2.1082) Cc: v6ops v6ops , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:56:30 -0000 Hi Daniel, Le 8 f=E9vr. 2011 =E0 14:40, Keith Moore a =E9crit : > On Feb 8, 2011, at 2:31 AM, Daniel Roesen wrote: > On Tue, Feb 08, 2011 at 12:44:41AM -0500, Keith Moore wrote: >>> 1. ISPs that want to impose CGNs on their customers before providing >>> them any way to use v6 at all. >> Replace "want to" by "need to". >=20 > I don't really buy "need to". There are lots of ways to better = allocate existing IPv4 addresses that are probably applicable to most = networks. =20 E.g. 4rd (described in tools.ietf.org/id/draft-despres-softwire-4rd-00, = intended to be deployed by 4 Japanese ISPs) Regards, RD From mohacsi@niif.hu Tue Feb 8 09:56:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2673A67F9 for ; Tue, 8 Feb 2011 09:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tC9uN2HmYjrE for ; Tue, 8 Feb 2011 09:56:37 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 62BAF3A66B4 for ; Tue, 8 Feb 2011 09:56:37 -0800 (PST) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id 655A986B71; Tue, 8 Feb 2011 18:56:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id SbLJ-PiGTTSb; Tue, 8 Feb 2011 18:56:27 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id EAA8D86BCB; Tue, 8 Feb 2011 18:56:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id E7E3086BBB; Tue, 8 Feb 2011 18:56:27 +0100 (CET) Date: Tue, 8 Feb 2011 18:56:27 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Jack Bates In-Reply-To: <4D518248.3000900@brightok.net> Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> <4D515EE7.1080008@brightok.net> <4D516522.9050007@brightok.net> <4BF9DA98-DBD9-4658-A28A-C1463B3808C1@network-heretics.com> <4D518248.3000900@brightok.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:56:38 -0000 On Tue, 8 Feb 2011, Jack Bates wrote: > > > On 2/8/2011 11:17 AM, Keith Moore wrote: >> On Feb 8, 2011, at 10:45 AM, Jack Bates wrote: >> >>> On 2/8/2011 9:40 AM, Ted Lemon wrote: >>>> I'm not following your argument here. Presumably if you get a >>>> AAAA, and you have v6 connectivity, you will connect >>>> successfully. If you get an A and an AAAA, you will still >>>> connect successfully. And if you get an A, you *might* connect >>>> successfully, if the LSN isn't overloaded, and if the NAT doesn't >>>> break something simply because it modified the packets in >>>> transit. Where's the case where adding working v6 makes things >>>> worse? >>>> >>> >>> Grandma goes to some website that has AAAA advertised and their >>> IPv6 address isn't on my Internet. >>> >>> Grandma hits a DNS load balancer that responds to AAAA with >>> nxdomain. >>> >>> For every customer I turn up on IPv6, I find more brokenness. >> >> Well, sure. There are lots of things in the net, like interception >> proxies, that are IPv6 naive. >> > > I think you missed my point. > > 1) There are isolations in the core network. Baking cakes hasn't fixed them > yet. > > > 2) There are DNS servers which nxdomain AAAA records (which means fallback to > A isn't an option). > > This has nothing to do with things in the middle that are intercepting and > causing havoc (doesn't matter if the DNS is answered by a load balancer or an > auth server, if it responds poorly to AAAA, it fails). Fix the DNS servers. > > The IPv6 network is broken until core networks fix pathing and peering > issues. End of story. Until that occurs, putting average joe on IPv6 is > asking them to have a horrible experience. Can you list pathing and peering issues.... If these problems did not fixed, then users will stop using that provider.... Best Regards, Janos Mohacsi From jbates@brightok.net Tue Feb 8 10:03:47 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136563A679F for ; Tue, 8 Feb 2011 10:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.217 X-Spam-Level: X-Spam-Status: No, score=-3.217 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scnxrIQW6baf for ; Tue, 8 Feb 2011 10:03:46 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 4CCEF3A672E for ; Tue, 8 Feb 2011 10:03:46 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18I3peC019111; Tue, 8 Feb 2011 12:03:51 -0600 (CST) Message-ID: <4D518586.30105@brightok.net> Date: Tue, 08 Feb 2011 12:03:50 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mohacsi Janos References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> <4D515EE7.1080008@brightok.net> <4D516522.9050007@brightok.net> <4BF9DA98-DBD9-4658-A28A-C1463B3808C1@network-heretics.com> <4D518248.3000900@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:03:47 -0000 On 2/8/2011 11:56 AM, Mohacsi Janos wrote: > Can you list pathing and peering issues.... If these problems did not > fixed, then users will stop using that provider.... > Read NANOG archives. There's a long list. Just to hit a big one, No level3 customer can reach any HE customer (or google for that matter). I believe Cogent and HE are still divided. There are more, though I'm still waiting on NSP PE support for v6 from my other transits. Jack From jbates@brightok.net Tue Feb 8 10:05:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722483A67E2 for ; Tue, 8 Feb 2011 10:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.218 X-Spam-Level: X-Spam-Status: No, score=-3.218 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-ywcc9CQ2vy for ; Tue, 8 Feb 2011 10:05:44 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 8A9063A672E for ; Tue, 8 Feb 2011 10:05:44 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18I5oqQ019643; Tue, 8 Feb 2011 12:05:50 -0600 (CST) Message-ID: <4D5185FD.5070303@brightok.net> Date: Tue, 08 Feb 2011 12:05:49 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mohacsi Janos References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> <4D515EE7.1080008@brightok.net> <4D516522.9050007@brightok.net> <4BF9DA98-DBD9-4658-A28A-C1463B3808C1@network-heretics.com> <4D518248.3000900@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:05:45 -0000 On 2/8/2011 11:56 AM, Mohacsi Janos wrote: > > Fix the DNS servers. > They are not my DNS servers to fix. In addition, customers often won't recognize the problem and just sit at home grumbling about how crappy our service is. Jack From Fred.L.Templin@boeing.com Tue Feb 8 10:06:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94C933A6807; Tue, 8 Feb 2011 10:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.097 X-Spam-Level: X-Spam-Status: No, score=-6.097 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrh-cbVyQog7; Tue, 8 Feb 2011 10:06:08 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 6D9AA3A680B; Tue, 8 Feb 2011 10:06:08 -0800 (PST) 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 p18I67ZH002281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 10:06:10 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p18I64DE014270; Tue, 8 Feb 2011 10:06:06 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p18I54J0011038 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 8 Feb 2011 10:06:02 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Tue, 8 Feb 2011 10:05:58 -0800 From: "Templin, Fred L" To: "Roman.Arcea@orange.md" , Cameron Byrne Date: Tue, 8 Feb 2011 10:05:57 -0800 Thread-Topic: when to tunnel vs. when to go native (was: RE: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00) Thread-Index: AcvHsCqXAvwUngrZSZiATm73XE8fBQABgcwg Message-ID: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net><4D50626A .8020801@gmail.com> <49 12B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@ redpill-linpro.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: IPv6 Operations , Keith Moore , "v6ops-bounces@ietf.org" Subject: [v6ops] when to tunnel vs. when to go native (was: RE: Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:06:09 -0000 Time out. There is an aspect of this discussion that is being (I think unintentionally) glossed over, but that needs a deeper analysis. That being, when is it beneficial to tunnel vs. when to go native? Tunneling is useful for much more than just incremental deployment of IPv6 over IPv4 networks. Tunneling is useful for mobility management, multihoming, traffic engineering, security (e.g., VPNs), and more. But that said, no one is saying nor should it be advocated that there is no place for native IPv6. To the contrary, there are many instances in which native IPv6 makes far more sense than tunneled. For instance, major Internet service presences like google, yahoo, facebook, etc. (just to name a few) have no reason to tunnel. They aren't going anywhere, their services don't require strong encryption, and they're big enough that they can get their (multiple?) ISPs to advertise their PI IPv6 prefixes into the native IPv6 DFZ. Large enterprise networks fit the same description. However, small- to medium-sized end user networks (EUNs) may not be big enough to pump their PI prefixes into their providers' routing systems, yet they may want to multi-home, to move around, to perform both out-bound and in-bound traffic engineering, to VPN into their home offices, etc. The small- to mid-sized EUNs are therefore the realm where tunneling makes sense as a long-term solution. Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Roman.Arcea@orange.md > Sent: Tuesday, February 08, 2011 8:48 AM > To: Cameron Byrne > Cc: v6ops-bounces@ietf.org; IPv6 Operations; Keith Moore > Subject: Re: [v6ops] Fwd: New Version Notificationfor=20 > draft-troan-v6ops-6to4-to-historic-00 >=20 > v6ops-bounces@ietf.org wrote on 08-02-2011 18:32:27: >=20 > > From: Cameron Byrne > > To: Tore Anderson > > Cc: IPv6 Operations , Keith Moore=20 > > > Date: 08-02-11 18:32 > > Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan- > > v6ops-6to4-to-historic-00 > > Sent by: v6ops-bounces@ietf.org > >=20 > > On Tue, Feb 8, 2011 at 7:36 AM, Tore Anderson > > wrote: > > > Hi, > > > > > > * Keith Moore > > > > > >> 6to4 is not harmful to IPv6 deployment. ISPs that break IPv4 are > > >> harmful to IPv6 deployment. > > > > > > 6to4 was the major reason why I had to delay deploying=20 > AAAAs for the > > > sites I host. Instead of being able to deploy, I had to=20 > run around for > > > more than a year begging hardware and OS vendors to turn it off. > > > > > > So yes, 6to4 is very harmful to people wanting to deploy=20 > IPv6. Why do > > > you think is seen as necessary? > > > > > >>> 6to4 is what is distracting us. having to fix=20 > brokenness triggered > > >>> by 6to4. > > > > > > Precisely. > > > > > >> I think the statement in a nutshell is this: as long as operators > > >> insist on seeing 6to4 as a 'problem' rather than a way to provide > > >> their customers good service and a useful transition=20 > tool, they're > > >> going to keep sabotaging it. By doing so they're=20 > actually impairing > > >> deployment of IPv6. > > > > > > Reverse 6to4 relays deployed close to the content? Check. > > > > > > That doesn't fix the problem, though. There's nothing I,=20 > or any other > > > individual network operator, can do to fix it. In order=20 > for 6to4 to=20 > work > > > reliably, *everyone* must play along. And that's simply=20 > not going to=20 > happen. > > > > > > 6to4 was a fun little toy for people who wanted to=20 > experiment with=20 > IPv6. > > > It is completely unsuitable to be Mr. John Q. Public's=20 > generic IPv6 > > > internet connectivity. At this point in time, *real* IPv6=20 > deployments=20 > is > > > necessary, and 6to4 is just getting in the way. It's time=20 > to shelve=20 > it. > > > >=20 > > This is the conclusion i believe you will hear from all network > > operators that are really doing IPv6 now. I am not sure what it is > > about tunneled IPv6 access that makes their creators so=20 > adamant about > > it ... It's really native v4/v4v6/v6 or nothing on the real=20 > internet. > > Why? Because people don't care about IP versions, and a tunnel is > > never worth it. They care that facebook works. Everything else is > > just pedantry. >=20 >=20 > +1 to what Tore and Cameron say >=20 > I am running a private 6to4 relay for my customers only. This=20 > indeed makes=20 > the service much better. However, as long as the return path=20 > is out of my=20 > control, it is not near as good as the native IPv6 I have and=20 > is just a=20 > hobby, not nearly a real service I can offer support for. And=20 > no, I don't=20 > have the issues Cameron currently has with the address space,=20 > in which=20 > situation 6to4 becomes the worst thing you could ever=20 > imagine. In a year=20 > from now, the 6to4 will become a dead end. > To be frank, as long as their is a solution that in any way stops the=20 > content providers to serve AAAAs, it is bad. At this critical=20 > time, we=20 > should not get distracted with any hacks. Forget tunneling,=20 > put time in=20 > native IPv6, commit to content owners to have them doing it=20 > as well, and=20 > as soon as a large part of Alexa 1M is on IPv6, the things will start=20 > sorting themselves out. >=20 > Best, > Roman=20 >=20 >=20 > > _______________________________________________ > > 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 moore@network-heretics.com Tue Feb 8 10:09:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8313A67E2 for ; Tue, 8 Feb 2011 10:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUDPUspKzqy7 for ; Tue, 8 Feb 2011 10:09:52 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 5354A3A67C0 for ; Tue, 8 Feb 2011 10:09:52 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Pms0f-0004JT-F1; Tue, 08 Feb 2011 13:09:55 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D518248.3000900@brightok.net> Date: Tue, 8 Feb 2011 13:09:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9EFE9F0A-A210-4AAD-880B-1F3709C14EE4@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> <4D515EE7.1080008@brightok.net> <4D516522.9050007@brightok.net> <4BF9DA98-DBD9-4658-A28A-C1463B3808C1@network-heretics.com> <4D518248.3000900@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9405c843a91f0fdab318a8a97e68ab7e90a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:09:53 -0000 On Feb 8, 2011, at 12:50 PM, Jack Bates wrote: > On 2/8/2011 11:17 AM, Keith Moore wrote: >> On Feb 8, 2011, at 10:45 AM, Jack Bates wrote: >>=20 >>> On 2/8/2011 9:40 AM, Ted Lemon wrote: >>>> I'm not following your argument here. Presumably if you get a >>>> AAAA, and you have v6 connectivity, you will connect >>>> successfully. If you get an A and an AAAA, you will still >>>> connect successfully. And if you get an A, you *might* connect >>>> successfully, if the LSN isn't overloaded, and if the NAT doesn't >>>> break something simply because it modified the packets in >>>> transit. Where's the case where adding working v6 makes things >>>> worse? >>>>=20 >>>=20 >>> Grandma goes to some website that has AAAA advertised and their >>> IPv6 address isn't on my Internet. >>>=20 >>> Grandma hits a DNS load balancer that responds to AAAA with >>> nxdomain. >>>=20 >>> For every customer I turn up on IPv6, I find more brokenness. >>=20 >> Well, sure. There are lots of things in the net, like interception >> proxies, that are IPv6 naive. >>=20 >=20 > I think you missed my point. >=20 > 1) There are isolations in the core network. Baking cakes hasn't fixed = them yet. yeah, I get that. those things need to be hunted down and fixed. > 2) There are DNS servers which nxdomain AAAA records (which means = fallback to A isn't an option). >=20 > This has nothing to do with things in the middle that are intercepting = and causing havoc (doesn't matter if the DNS is answered by a load = balancer or an auth server, if it responds poorly to AAAA, it fails). ah, I'm conflating several things here, probably because I've been stuck = before with an ISP that insists on intercepting traffic to port 43 = regardless of its destination, and imposing its own DNS server.=20 a) authoritative DNS servers that are broken. any domain offering AAAA = records should make sure that AAAA queries work. I think they probably = already do, for the most part. b) caching DNS servers that are broken. the operators of such servers = need to test to make sure that AAAA queries work properly. it's not = that hard. c) DNS interception proxies. really, those should be removed.... but I = assume the operators will refuse to remove them. so they need to be = fixed also. >> Again, it's not reasonable to blame IPv6 or 6to4 because they happen >> to explore brokenness that already exists in the IPv4 network. The >> blame lies squarely with the operators and equipment vendors. >=20 > The IPv6 network is broken until core networks fix pathing and peering = issues. End of story. Until that occurs, putting average joe on IPv6 is = asking them to have a horrible experience. So, in summary: a) IPv4 is broken both because of address scarcity and because there's a = large body of bad practice out there b) because IPv4 is broken, 6to4 is broken c) IPv6 is broken because it hasn't been well shaken down yet. It does look like some sort of triage is in order. Keith From jbates@brightok.net Tue Feb 8 10:12:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C4A93A67E2; Tue, 8 Feb 2011 10:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvnVktI-g1cc; Tue, 8 Feb 2011 10:12:19 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id C96453A67D6; Tue, 8 Feb 2011 10:12:19 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p18IBS2S017564; Tue, 8 Feb 2011 12:11:29 -0600 (CST) Message-ID: <4D51874F.9080803@brightok.net> Date: Tue, 08 Feb 2011 12:11:27 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Templin, Fred L" References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net><4D50626A .8020801@gmail.com> <49 12B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@ redpill-linpro.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Keith Moore , "v6ops-bounces@ietf.org" , IPv6 Operations Subject: Re: [v6ops] when to tunnel vs. when to go native X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:12:20 -0000 On 2/8/2011 12:05 PM, Templin, Fred L wrote: > The small- to mid-sized EUNs are therefore the realm > where tunneling makes sense as a long-term solution. I completely agree. 6to4 isn't the appropriate tunnel mechanism for that, though. Nor is it good for an ISP to look at such tunnels as a permanent solution for generic users. IRON has it's place, but I don't believe the ISP is it. Jack From moore@network-heretics.com Tue Feb 8 10:12:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D233D3A6803 for ; Tue, 8 Feb 2011 10:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOGmnUMaIU9W for ; Tue, 8 Feb 2011 10:12:24 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id BF75B3A6807 for ; Tue, 8 Feb 2011 10:12:23 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Pms3B-0000rp-RN; Tue, 08 Feb 2011 13:12:30 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-40-1053966025 From: Keith Moore In-Reply-To: Date: Tue, 8 Feb 2011 13:12:25 -0500 Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <8BB85FD2-408B-424E-835A-7991EA3B3DE2@network-heretics.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94003c79fcbcf7c7cae746a7080aeed4e00350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:12:24 -0000 --Apple-Mail-40-1053966025 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 8, 2011, at 12:52 PM, Templin, Fred L wrote: > Keith, > =20 > > that's great for corner cases, but it doesn't make for a general = solution. at least, not in the short term. > =20 > Not at all. For the price of a small S/W engineering investment, an > IRON service provider can offer a downloadable module for an existing > Windows, *BSD, MacOS, etc. platform as part of the arrangement > with the customer. It is then just a point-and-click operation away, > and the customer's EUN is up and running. The number of service providers that currently offer any kind of = software support for other than windows and maybe mac is very small. And yet, customers need to use platforms other than windows and maybe = mac. What makes you think that providers are going to suddenly start = supporting software for lots of platforms? What makes you think that their customers will be willing to trust them = enough to install their software? The reason we have protocol standards is so that we don't have to rely = on "running the right software" as the basis for interoperability. Keith --Apple-Mail-40-1053966025 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Feb 8, 2011, at 12:52 PM, Templin, Fred L wrote:

Keith,
 
> that's great for corner cases, but it doesn't make for a general solution.  at least, not in the short term.
 
Not at all. For the price of a small S/W engineering investment, an
IRON service provider can offer a downloadable module for an existing
Windows, *BSD, MacOS, etc. platform as part of the arrangement
with the customer. It is then just a point-and-click operation away,
and the customer's EUN is up and running.

The number of service providers that currently offer any kind of software support for other than windows and maybe mac is very small.
And yet, customers need to use platforms other than windows and maybe mac.
What makes you think that providers are going to suddenly start supporting software for lots of platforms?
What makes you think that their customers will be willing to trust them enough to install their software?

The reason we have protocol standards is so that we don't have to rely on "running the right software" as the basis for interoperability.

Keith


--Apple-Mail-40-1053966025-- From remi.despres@free.fr Tue Feb 8 10:15:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58BD73A67D6; Tue, 8 Feb 2011 10:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.066 X-Spam-Level: X-Spam-Status: No, score=-0.066 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_40=-0.185, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ps+WrtDYJ2Ud; Tue, 8 Feb 2011 10:15:02 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by core3.amsl.com (Postfix) with ESMTP id 522063A672F; Tue, 8 Feb 2011 10:15:02 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id ED65770000AB; Tue, 8 Feb 2011 19:15:08 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id 3ECDA70000A2; Tue, 8 Feb 2011 19:15:08 +0100 (CET) X-SFR-UUID: 20110208181508257.3ECDA70000A2@msfrf2212.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 8 Feb 2011 19:15:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <09975D14-0C97-4E3B-AA3C-D5F9200061C4@free.fr> References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@redpill-linpro.com> To: Roman.Arcea@orange.md X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , v6ops-bounces@ietf.org, Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:15:03 -0000 Le 8 f=E9vr. 2011 =E0 17:47, Roman.Arcea@orange.md a =E9crit : > To be frank, as long as their is a solution that in any way stops the=20= > content providers to serve AAAAs, it is bad. At this critical time, we=20= > should not get distracted with any hacks. > Forget tunneling, put time in=20 > native IPv6, Well 6rd, although it is a "tunneling" mechanism, permits rapid = deployment of native IPv6 addresses where, for some reason, natively = routing IPv6 in access networks is difficult. Where native routing of IPv6 is easy, it is a better solution than 6rd = but, where it isn't easy, I would rather call 6rd a "solution" than a = hack. It has been working fine on a multi-million customer network, for = several years now. Regards, RD From jbates@brightok.net Tue Feb 8 10:25:47 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306E43A6804 for ; Tue, 8 Feb 2011 10:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zToLO6W59VAh for ; Tue, 8 Feb 2011 10:25:46 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 27A623A6801 for ; Tue, 8 Feb 2011 10:25:46 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18IPne5024667; Tue, 8 Feb 2011 12:25:49 -0600 (CST) Message-ID: <4D518AAC.4010003@brightok.net> Date: Tue, 08 Feb 2011 12:25:48 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> <4D515EE7.1080008@brightok.net> <4D516522.9050007@brightok.net> <4BF9DA98-DBD9-4658-A28A-C1463B3808C1@network-heretics.com> <4D518248.3000900@brightok.net> <9EFE9F0A-A210-4AAD-880B-1F3709C14EE4@network-heretics.com> In-Reply-To: <9EFE9F0A-A210-4AAD-880B-1F3709C14EE4@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:25:47 -0000 On 2/8/2011 12:09 PM, Keith Moore wrote: > So, in summary: > > a) IPv4 is broken both because of address scarcity and because there's a large body of bad practice out there > b) because IPv4 is broken, 6to4 is broken > c) IPv6 is broken because it hasn't been well shaken down yet. > > It does look like some sort of triage is in order. Exactly, and most of this is due to, a) lack of market pressure (so things didn't move as early as they should have) b) ideas such as happy eyeballs should have been developed 10+ years ago c) Some implementations out right broke RFC standards Because of this, a) IPv4 will be broken much more than was necessary if market pressure had been 5+ years earlier b) Many transition tools are almost useless at this point c) The world is waiting on core networks to fix pathing issues (which they are rapidly doing due to market pressures). As soon as they do, the edge networks will light up like christmas trees (as many are just waiting on core networks). At which point content providers will happily turn on AAAA (as qos should be the same or better than IPv4 at that point). Those with broken implementations will just have to fix them. Jack From moore@network-heretics.com Tue Feb 8 10:26:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC6803A6801 for ; Tue, 8 Feb 2011 10:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLv7qekDzvNA for ; Tue, 8 Feb 2011 10:26:02 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id DE13A3A681B for ; Tue, 8 Feb 2011 10:26:01 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmsGN-0005Lk-II; Tue, 08 Feb 2011 13:26:09 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D515B41.7060409@brightok.net> Date: Tue, 8 Feb 2011 13:26:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <11CEE19E-3E9B-463C-9724-F57AC0C201EE@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> <1297147875.4205.34.camel@shakira.millnert.se> <1987A727-BD2F-4BAB-AB59-ED27033CE17F@network-heretics.com> <4D515B41.7060409@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9405188787a0e33e653c059a4e1ee9e5d8e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:26:03 -0000 On Feb 8, 2011, at 10:03 AM, Jack Bates wrote: > On 2/8/2011 12:57 AM, Keith Moore wrote: >> 6to4 is not the problem; the problem is breaking fundamental design >> assumptions in IP. It's not like 6to4 is the only thing in the v4 >> Internet that expects globally scoped addresses to be uniquely >> assigned to hosts. >=20 > Except that ARIN is proposing a /10 for this specific purpose (since = it failed the IETF). It will be just as broken with 6to4; as 6to4 uses a = hack to disable (RFC-1918 awareness) and using RFC-1918 for a CGN is = even worse than breaking 6to4. 6to4 implementations will learn to recognize that /10 in addition to RFC = 1918 prefixes. > Failed protocol. Someone should have set a flag for an ISP to specify = support or no support for 6to4, even a simple dns query would have done. = Too late now, operators will just break it. Ah yes, the "6to4 should have anticipated brain damage to be invented a = decade in the future" argument. Wrong. It's incumbent on CGN to = support everything people need out of IPv4, and that includes 6to4 or at = least v6. It was not at all unreasonable to expect IP service providers to support = the IP protocol. An fundamental characteristic of the IP protocol is = that addresses are uniquely assigned to hosts. > I realize their IPv6 trial doesn't help the thousands of clueless = windows 7 users, which is why the easiest hack is for t-mobile to = support 6to4 anycast + NAT66, but I doubt they have an implementation = for that yet. >=20 > Now, here's the import part. Rolling out pure IPv6 to everyone will = create it's own brokenness (6to4 policy is less used than pure IPv6 = policy). It will happen soon, but we aren't quite to that point yet and = there is a LOT of isolation issues. So there might be cases where 6to4 works better than native v6 even when = native v6 is provided. Interesting. I suppose someone will propose = deprecating native v6 for that reason.=20 Keith From jbates@brightok.net Tue Feb 8 10:28:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF873A6801; Tue, 8 Feb 2011 10:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.071 X-Spam-Level: X-Spam-Status: No, score=-3.071 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xFM5YOEZC4d; Tue, 8 Feb 2011 10:28:37 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 6772E3A67E9; Tue, 8 Feb 2011 10:28:37 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p18ISgWW021685; Tue, 8 Feb 2011 12:28:42 -0600 (CST) Message-ID: <4D518B59.4010201@brightok.net> Date: Tue, 08 Feb 2011 12:28:41 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@redpill-linpro.com> <09975D14-0C97-4E3B-AA3C-D5F9200061C4@free.fr> In-Reply-To: <09975D14-0C97-4E3B-AA3C-D5F9200061C4@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 Operations , v6ops-bounces@ietf.org, Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:28:38 -0000 On 2/8/2011 12:15 PM, Rémi Després wrote: > Well 6rd, although it is a "tunneling" mechanism, permits rapid > deployment of native IPv6 addresses where, for some reason, natively > routing IPv6 in access networks is difficult. Where native routing of > IPv6 is easy, it is a better solution than 6rd but, where it isn't > easy, I would rather call 6rd a "solution" than a hack. It has been > working fine on a multi-million customer network, for several years > now. 6rd, like PPPoX has the benefit of being localized tunneling. As such, it falls into a different category than internetwork tunneling. Jack From remi.despres@free.fr Tue Feb 8 10:33:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B2A3A6805 for ; Tue, 8 Feb 2011 10:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_05=-1.11, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpT5NhhXqfxQ for ; Tue, 8 Feb 2011 10:33:12 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by core3.amsl.com (Postfix) with ESMTP id 453453A6801 for ; Tue, 8 Feb 2011 10:33:12 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id A3D5A7000093; Tue, 8 Feb 2011 19:33:18 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 4AA667000084; Tue, 8 Feb 2011 19:33:18 +0100 (CET) X-SFR-UUID: 20110208183318305.4AA667000084@msfrf2216.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20110208170421.GW44800@Space.Net> Date: Tue, 8 Feb 2011 19:33:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1A32BA6A-F803-4231-B7C2-9C88E55A79E4@free.fr> References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@redpill-linpro.com> <20110208170421.GW44800@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:33:13 -0000 Le 8 f=E9vr. 2011 =E0 18:04, Gert Doering a =E9crit : > Hi, >=20 > On Tue, Feb 08, 2011 at 09:00:36AM -0800, james woodyatt wrote: >> On Feb 8, 2011, at 07:36, Tore Anderson wrote: >>>=20 >>> At this point in time, *real* IPv6 deployments is necessary, and = 6to4 is just getting in the way. It's time to shelve it. >>=20 >> Agreed. When it's all packed up and reposing gently on a shelf = somewhere-- and *not* widely used on the public IPv4 anymore-- then I = will agree that moving 6to4-anycast to Historic is proper use of IETF = time. Not yet. >=20 > Well, what would you see as necessary to make vendors disable 6to4 in > their default configuration? Apple already did, as far as I'm aware, > and that's great :-) - so now we just need to convince the rest... >=20 > Declaring 6to4 "historic" might just be the message to send to = vendors. IMHO: - 6to4 disabled by default is a clear and *necessary* message. - Declaring that 6to4 is "historic" is debatable, confusing, and *not = necessary". Regards, RD =20 From cb.list6@gmail.com Tue Feb 8 10:33:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966833A6825 for ; Tue, 8 Feb 2011 10:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXfsOQRhoBIp for ; Tue, 8 Feb 2011 10:33:20 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 507C53A6823 for ; Tue, 8 Feb 2011 10:33:20 -0800 (PST) Received: by qwi2 with SMTP id 2so4723736qwi.31 for ; Tue, 08 Feb 2011 10:33:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ywbv705fSGRFYuzarcIcco7nH6UcKGPjguasdDKm9oY=; b=ZZhfle2cRPp4+ys8NSv/D05jRQCKJ5dzvmK6LliM83wpzxhmG1/NRETfGLuXZYNUu7 wNQbBzo7POAF0VDUsemHYwos5F5ttIawknbK2+SY81RGGIMiKTfqfk8ifTTYXSQmbBT2 z8paNdwv3OGUwWPf+K5YZCxkQmUH0Y/3tPyhM= 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=KCP9G2GTA/C32Hexs5AUK2luwD1nSKjmpI20hkzRspuIONZfYhmoVickBiy8f7ohxr 8EBFA/gNsVNbJLtEzI5STvEopvcJ8CRrG5dYDnt96o/s6jtQtPKqinZQ7j1EAyYlrKCk Cl0BLQb8hDUM3BnM3eBqUPUpRbEBpgQPrk08g= MIME-Version: 1.0 Received: by 10.229.87.149 with SMTP id w21mr12256769qcl.68.1297190007515; Tue, 08 Feb 2011 10:33:27 -0800 (PST) Received: by 10.229.224.79 with HTTP; Tue, 8 Feb 2011 10:33:27 -0800 (PST) In-Reply-To: <9EFE9F0A-A210-4AAD-880B-1F3709C14EE4@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> <4D515EE7.1080008@brightok.net> <4D516522.9050007@brightok.net> <4BF9DA98-DBD9-4658-A28A-C1463B3808C1@network-heretics.com> <4D518248.3000900@brightok.net> <9EFE9F0A-A210-4AAD-880B-1F3709C14EE4@network-heretics.com> Date: Tue, 8 Feb 2011 10:33:27 -0800 Message-ID: From: Cameron Byrne To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:33:21 -0000 On Tue, Feb 8, 2011 at 10:09 AM, Keith Moore w= rote: > On Feb 8, 2011, at 12:50 PM, Jack Bates wrote: > >> On 2/8/2011 11:17 AM, Keith Moore wrote: >>> On Feb 8, 2011, at 10:45 AM, Jack Bates wrote: >>> >>>> On 2/8/2011 9:40 AM, Ted Lemon wrote: >>>>> I'm not following your argument here. =A0 Presumably if you get a >>>>> AAAA, and you have v6 connectivity, you will connect >>>>> successfully. =A0 If you get an A and an AAAA, you will still >>>>> connect successfully. =A0 And if you get an A, you *might* connect >>>>> successfully, if the LSN isn't overloaded, and if the NAT doesn't >>>>> break something simply because it modified the packets in >>>>> transit. =A0 Where's the case where adding working v6 makes things >>>>> worse? >>>>> >>>> >>>> Grandma goes to some website that has AAAA advertised and their >>>> IPv6 address isn't on my Internet. >>>> >>>> Grandma hits a DNS load balancer that responds to AAAA with >>>> nxdomain. >>>> >>>> For every customer I turn up on IPv6, I find more brokenness. >>> >>> Well, sure. =A0There are lots of things in the net, like interception >>> proxies, that are IPv6 naive. >>> >> >> I think you missed my point. >> >> 1) There are isolations in the core network. Baking cakes hasn't fixed t= hem yet. > > yeah, I get that. =A0those things need to be hunted down and fixed. > >> 2) There are DNS servers which nxdomain AAAA records (which means fallba= ck to A isn't an option). >> >> This has nothing to do with things in the middle that are intercepting a= nd causing havoc (doesn't matter if the DNS is answered by a load balancer = or an auth server, if it responds poorly to AAAA, it fails). > > ah, I'm conflating several things here, probably because I've been stuck = before with an ISP that insists on intercepting traffic to port 43 regardle= ss of its destination, and imposing its own DNS server. > > a) authoritative DNS servers that are broken. =A0any domain offering AAAA= records should make sure that AAAA queries work. =A0I think they probably = already do, for the most part. > b) caching DNS servers that are broken. =A0the operators of such servers = need to test to make sure that AAAA queries work properly. =A0it's not that= hard. > c) DNS interception proxies. =A0really, those should be removed.... but I= assume the operators will refuse to remove them. =A0so they need to be fix= ed also. > >>> Again, it's not reasonable to blame IPv6 or 6to4 because they happen >>> to explore brokenness that already exists in the IPv4 network. =A0The >>> blame lies squarely with the operators and equipment vendors. >> >> The IPv6 network is broken until core networks fix pathing and peering i= ssues. End of story. Until that occurs, putting average joe on IPv6 is aski= ng them to have a horrible experience. > > So, in summary: > > a) IPv4 is broken both because of address scarcity and because there's a = large body of bad practice out there > b) because IPv4 is broken, 6to4 is broken > c) IPv6 is broken because it hasn't been well shaken down yet. > You forgot that 6to4 is broken and therefore slows down IPv6 content deployment and drives up ISP helpdesk calls. > It does look like some sort of triage is in order. > > Keith > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From jbates@brightok.net Tue Feb 8 10:34:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC723A6821 for ; Tue, 8 Feb 2011 10:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRofB8JJuz2J for ; Tue, 8 Feb 2011 10:34:40 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 8EBBC3A6816 for ; Tue, 8 Feb 2011 10:34:39 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p18IYjkc023216; Tue, 8 Feb 2011 12:34:46 -0600 (CST) Message-ID: <4D518CC5.1080806@brightok.net> Date: Tue, 08 Feb 2011 12:34:45 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> <1297147875.4205.34.camel@shakira.millnert.se> <1987A727-BD2F-4BAB-AB59-ED27033CE17F@network-heretics.com> <4D515B41.7060409@brightok.net> <11CEE19E-3E9B-463C-9724-F57AC0C201EE@network-heretics.com> In-Reply-To: <11CEE19E-3E9B-463C-9724-F57AC0C201EE@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:34:43 -0000 On 2/8/2011 12:26 PM, Keith Moore wrote: > It was not at all unreasonable to expect IP service providers to > support the IP protocol. An fundamental characteristic of the IP > protocol is that addresses are uniquely assigned to hosts. > That ship sailed with the invention of NAT. LSN breaks many of the workaround designed for NAT. It will happily break 6to4 as well. While a very weird ALG could be built for 6to4, it would require NAT of the 6to4 addressing. Why won't IPv4 hang around forever on the public Internet? It's not cost effective to support it and LSN will be the final breakage of it. on issues. > So there might be cases where 6to4 works better than native v6 even > when native v6 is provided. Interesting. I suppose someone will > propose deprecating native v6 for that reason. Only because 6to4 anycast isn't used if an A record exists. Once core routing is resolved, pure IPv6 will be the way to go (6rd for localized tunneling if necessary). Jack From cb.list6@gmail.com Tue Feb 8 10:35:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F02E3A682B for ; Tue, 8 Feb 2011 10:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.363 X-Spam-Level: X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o++5iNRYqd-r for ; Tue, 8 Feb 2011 10:35:10 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 63E643A682E for ; Tue, 8 Feb 2011 10:35:10 -0800 (PST) Received: by qyj19 with SMTP id 19so4651849qyj.10 for ; Tue, 08 Feb 2011 10:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=W/fXzKF/WaVzeaRdUppZU6qcUimcfKny46JcpYLNpkI=; b=dDgARAUeHto4mX1u9oSgQmCfs4Srh1r0btsOwh8tKApYmNmqT/8IRTr8eoMF9OyTba UnQbtz2mXtuUNRXqmnO+lALetfV2TrgY0c8FaVX2R8H5Pfwovfpfd3j8Quq9Kz+nLW6+ kZ8N9l7UC5No9C6viCItlsU8XcuY+uNfTF+Nk= 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=qZq8dmocLKzivhfmiEOMDxk4b/WhWDdlIxZjJNPMG+CUIHXmekt5S3AxTjP/kk2FaL UBJB96Pg11Eph6vzLlZb6Vo2sSALgZoiyoWGstJUrPKPTGr3spc8CAGatof8xE1YRvvw 3cNfcO3w3ZGJXorLgmSQHJBNrK6d9FDxSDSVU= MIME-Version: 1.0 Received: by 10.229.87.149 with SMTP id w21mr12258606qcl.68.1297190117522; Tue, 08 Feb 2011 10:35:17 -0800 (PST) Received: by 10.229.224.79 with HTTP; Tue, 8 Feb 2011 10:35:17 -0800 (PST) In-Reply-To: <1A32BA6A-F803-4231-B7C2-9C88E55A79E4@free.fr> References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@redpill-linpro.com> <20110208170421.GW44800@Space.Net> <1A32BA6A-F803-4231-B7C2-9C88E55A79E4@free.fr> Date: Tue, 8 Feb 2011 10:35:17 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:35:11 -0000 On Tue, Feb 8, 2011 at 10:33 AM, R=E9mi Despr=E9s wr= ote: > > Le 8 f=E9vr. 2011 =E0 18:04, Gert Doering a =E9crit : > >> Hi, >> >> On Tue, Feb 08, 2011 at 09:00:36AM -0800, james woodyatt wrote: >>> On Feb 8, 2011, at 07:36, Tore Anderson wrote: >>>> >>>> At this point in time, *real* IPv6 deployments is necessary, and 6to4 = is just getting in the way. It's time to shelve it. >>> >>> Agreed. =A0When it's all packed up and reposing gently on a shelf somew= here-- and *not* widely used on the public IPv4 anymore-- then I will agree= that moving 6to4-anycast to Historic is proper use of IETF time. =A0Not ye= t. >> >> Well, what would you see as necessary to make vendors disable 6to4 in >> their default configuration? =A0Apple already did, as far as I'm aware, >> and that's great :-) - so now we just need to convince the rest... >> >> Declaring 6to4 "historic" might just be the message to send to vendors. > > IMHO: > - 6to4 disabled by default is a clear and *necessary* message. I agree with this. Good work RD. > - Declaring that 6to4 is "historic" is debatable, confusing, and *not nec= essary". Either way. I just don't want unknowing users being broke because 6to4 is on by default. From dr@cluenet.de Tue Feb 8 10:35:47 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A3E83A6825 for ; Tue, 8 Feb 2011 10:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKqhlxLOemtu for ; Tue, 8 Feb 2011 10:35:46 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 562B63A682B for ; Tue, 8 Feb 2011 10:35:46 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id F0AB61080D1; Tue, 8 Feb 2011 19:35:52 +0100 (CET) Date: Tue, 8 Feb 2011 19:35:52 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110208183552.GA28211@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@redpill-linpro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D5162E4.1020606@redpill-linpro.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:35:47 -0000 On Tue, Feb 08, 2011 at 04:36:04PM +0100, Tore Anderson wrote: > At this point in time, *real* IPv6 deployments is > necessary, and 6to4 is just getting in the way. It's time to shelve it. Cannot agree more. And it would make our support folks job MUCH easier if there won't be all that 6to4/Teredo/ISATAP/GreatIdeaOfTheDay in Windows boxes of end users when having to troubleshoot "Internet problems" customers. We don't only need to train them about Dual Stack operations (with all the nitty gritty details where and how things can go wrong there), we'll also need to educate them about all the problems introduced by those "automatic transition technologies". Nightmare. :-( Best regards, Daniel (who had to explain someone who thought to "have IPv6" what 6to4 is just last week) -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From Ted.Lemon@nominum.com Tue Feb 8 10:37:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D75D3A6802 for ; Tue, 8 Feb 2011 10:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-Gv4Drddr3P for ; Tue, 8 Feb 2011 10:37:18 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 898183A67E1 for ; Tue, 8 Feb 2011 10:37:18 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTVGNZdZkhwEfS8h8tv15Ysq3/O+9MqHm@postini.com; Tue, 08 Feb 2011 10:37:26 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F130B1B83B7 for ; Tue, 8 Feb 2011 10:37:24 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D6AB1190052; Tue, 8 Feb 2011 10:37:24 -0800 (PST) (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; Tue, 8 Feb 2011 10:37:24 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <2AD4DD41-50F9-4837-A33D-4E725323AA56@network-heretics.com> Date: Tue, 8 Feb 2011 13:37:19 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <132A9FE8-6CA9-4ACE-A30B-40668FFB784F@nominum.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <4D514EAB.3070109@brightok.net> <0BDAB499-AAE2-432B-B7C7-C2F03744FC93@network-heretics.com> <2AD4DD41-50F9-4837-A33D-4E725323AA56@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:37:19 -0000 On Feb 8, 2011, at 12:53 PM, Keith Moore wrote: > So I think there's a huge benefit in leveraging the 6to4 support that = already exists in most hosts. But hey, native v6 is even better. Unfortunately I think the number of people for whom this matters is = quite small, because it requires expertise to make it work. Like it or = not, the people we want to be using IPv6 are people like my mom and dad, = not people like you and me. Obviously you and I want to use it too, = but we aren't the customer whose needs are blocking widespread = deployment at the moment. From remi.despres@free.fr Tue Feb 8 10:40:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9411A3A6823 for ; Tue, 8 Feb 2011 10:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cJUug8H0WbD for ; Tue, 8 Feb 2011 10:40:43 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by core3.amsl.com (Postfix) with ESMTP id CB82D3A681E for ; Tue, 8 Feb 2011 10:40:42 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id EDCA7700009E; Tue, 8 Feb 2011 19:40:49 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 9304D7000081; Tue, 8 Feb 2011 19:40:49 +0100 (CET) X-SFR-UUID: 20110208184049602.9304D7000081@msfrf2216.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 8 Feb 2011 19:40:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <64800186-BC9B-4F76-8DBC-FDC13E017020@free.fr> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:40:43 -0000 Le 8 f=E9vr. 2011 =E0 18:12, Templin, Fred L a =E9crit : > ... IRON is not intended as only a transition > mechanism. IRON is tunnels-done-right, This seems to imply that 6rd tunnels wouldn't be done right. For rapid deployment of native IPv6 addresses where access network = aren't ready for IPv6 native routing, 6rd is AFAIK both done right AND = sufficient. Regards, RD From Fred.L.Templin@boeing.com Tue Feb 8 10:41:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD9C3A681E; Tue, 8 Feb 2011 10:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.39 X-Spam-Level: X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9K+oTIbBldB; Tue, 8 Feb 2011 10:41:16 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 1E54E3A6816; Tue, 8 Feb 2011 10:41:16 -0800 (PST) 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 p18IfHFU018883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 12:41:17 -0600 (CST) 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 p18IfHeX016030; Tue, 8 Feb 2011 12:41:17 -0600 (CST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p18IfGML015989 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 8 Feb 2011 12:41:17 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Tue, 8 Feb 2011 10:41:16 -0800 From: "Templin, Fred L" To: Jack Bates Date: Tue, 8 Feb 2011 10:41:14 -0800 Thread-Topic: [v6ops] when to tunnel vs. when to go native Thread-Index: AcvHu8zvGOkPvgFRQbuGejOglUNNWQAAaFow Message-ID: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net><4D50626 A .8020801@gmail.com> < 49 12B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.10206 06@ redpill-linpro.com> <4D51874F.9080803@brightok.net> In-Reply-To: <4D51874F.9080803@brightok.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Keith Moore , "v6ops-bounces@ietf.org" , IPv6 Operations Subject: Re: [v6ops] when to tunnel vs. when to go native X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:41:17 -0000 Hi Jack, > On 2/8/2011 12:05 PM, Templin, Fred L wrote: > > The small- to mid-sized EUNs are therefore the realm > > where tunneling makes sense as a long-term solution. >=20 > I completely agree. 6to4 isn't the appropriate tunnel mechanism for=20 > that, though. Nor is it good for an ISP to look at such tunnels as a=20 > permanent solution for generic users. >=20 > IRON has it's place, but I don't believe the ISP is it. The ISP provides an Internet connectivity service to its customers. But, there is nothing an ISP can do to stop its customers from also obtaining alernate Internet connectivity services through other providers. Couple that with the fact that multi-access end systems are common today, and will only become moreso going into the future. For example, take a hypothetical cellular operator "FOO" that provides a pay-as-you-go 3G/4G Internet connectivity service to its customers but knows full well that the customers will prefer to use WiFi whenever they are in range of an open-access for-free WiFi network. There is nothing the operator can do to stop that, but if they were to offer an IRON service to the customer then the ISP would still be involved even when the customer is not using the 3G/4G link, and the customers would be happy to have seamless multi-access capabilities. So, the benevolent ISP would be doing both themselves and their customers a favor by allowing open multi- access but possibly taking a small fee for the service. Sort of like how major banks allow their customers to use their competitors' ATM machines, only in a way that the customer doesn't get unduly over-charged. And, what better way to inspire customer loyalty? Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Templin, Fred L=20 > Sent: Tuesday, February 08, 2011 10:06 AM > To: 'Roman.Arcea@orange.md'; Cameron Byrne > Cc: v6ops-bounces@ietf.org; IPv6 Operations; Keith Moore > Subject: when to tunnel vs. when to go native (was: RE:=20 > [v6ops] Fwd: New Version Notificationfor=20 > draft-troan-v6ops-6to4-to-historic-00) >=20 > Time out. >=20 > There is an aspect of this discussion that is being > (I think unintentionally) glossed over, but that needs > a deeper analysis. That being, when is it beneficial > to tunnel vs. when to go native? >=20 > Tunneling is useful for much more than just incremental > deployment of IPv6 over IPv4 networks. Tunneling is > useful for mobility management, multihoming, traffic > engineering, security (e.g., VPNs), and more. >=20 > But that said, no one is saying nor should it be > advocated that there is no place for native IPv6. > To the contrary, there are many instances in which > native IPv6 makes far more sense than tunneled. For > instance, major Internet service presences like google, > yahoo, facebook, etc. (just to name a few) have no > reason to tunnel. They aren't going anywhere, their > services don't require strong encryption, and they're > big enough that they can get their (multiple?) ISPs to > advertise their PI IPv6 prefixes into the native IPv6 > DFZ. Large enterprise networks fit the same description. >=20 > However, small- to medium-sized end user networks (EUNs) > may not be big enough to pump their PI prefixes into > their providers' routing systems, yet they may want to > multi-home, to move around, to perform both out-bound > and in-bound traffic engineering, to VPN into their home > offices, etc. >=20 > The small- to mid-sized EUNs are therefore the realm > where tunneling makes sense as a long-term solution. >=20 > Thanks - Fred > fred.l.templin@boeing.com = From dr@cluenet.de Tue Feb 8 10:50:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39C653A681E for ; Tue, 8 Feb 2011 10:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAj-6oZA47on for ; Tue, 8 Feb 2011 10:50:43 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id D061B3A67D6 for ; Tue, 8 Feb 2011 10:50:42 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id D3BCB1080D3; Tue, 8 Feb 2011 19:50:49 +0100 (CET) Date: Tue, 8 Feb 2011 19:50:49 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110208185049.GB28211@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:50:44 -0000 On Tue, Feb 08, 2011 at 08:59:42AM -0500, Keith Moore wrote: > Well, it seems to me that 6to4 is yet another thing that users want to do with CGN, The amount of users who "want to do 6to4" you can search for with a magnifier glass. If anything, people want to "have IPv6". And 6to4 brokeness and thus IPv6 brokeness will skyrocket as soon as fast growing residential ISP will start to deploy LSN. Which WILL happen in my universe because it's unavoidable. What will be the rainbow IT press partyline: "disable IPv6, that fixes it". Great. Global anycast 6to4 is a problem, not a solution. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From Fred.L.Templin@boeing.com Tue Feb 8 11:01:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA8E3A67F5 for ; Tue, 8 Feb 2011 11:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAgfqPzQTUbg for ; Tue, 8 Feb 2011 11:01:37 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 292303A672E for ; Tue, 8 Feb 2011 11:01:37 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p18J1gI7002153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 13:01:43 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p18J1gSN018022; Tue, 8 Feb 2011 11:01:42 -0800 (PST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p18J1fP0017982 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 8 Feb 2011 11:01:41 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Tue, 8 Feb 2011 11:01:41 -0800 From: "Templin, Fred L" To: Keith Moore Date: Tue, 8 Feb 2011 11:01:40 -0800 Thread-Topic: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 Thread-Index: AcvHwMry7fX3U3Q2QxWAPrtJv4HP7gAADqow Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <8BB85FD2-408B-424E-835A-7991EA3B3DE2@network-heretics.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: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:01:38 -0000 Keith, =20 The parts of IRON that need to function according to open specifications are already covered under the core mechanisms known as VET and SEAL: http://tools.ietf.org/html/draft-templin-intarea-vet http://tools.ietf.org/html/draft-templin-intarea-seal That said, the piece of IRON that need not be standardized is the client-to-server tunnel setup negotiations. There is no reason for that to be part of the standard. Thanks - Fred fred.l.templin@boeing.com (RTF has made this difficult to annotate. Everyone else uses plaintext. Can we switch back to plaintext, please?) ________________________________ From: Keith Moore [mailto:moore@network-heretics.com]=20 Sent: Tuesday, February 08, 2011 10:12 AM To: Templin, Fred L Cc: Fred Baker; IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6t= o4-to-historic-00 =09 =09 On Feb 8, 2011, at 12:52 PM, Templin, Fred L wrote: Keith, =20 > that's great for corner cases, but it doesn't make for a general soluti= on. at least, not in the short term. =20 Not at all. For the price of a small S/W engineering investment, an IRON service provider can offer a downloadable module for an existing Windows, *BSD, MacOS, etc. platform as part of the arrangement with the customer. It is then just a point-and-click operation away, and the customer's EUN is up and running. The number of service providers that currently offer any kind of software = support for other than windows and maybe mac is very small. And yet, customers need to use platforms other than windows and maybe mac. What makes you think that providers are going to suddenly start supporting= software for lots of platforms? What makes you think that their customers will be willing to trust them en= ough to install their software? The reason we have protocol standards is so that we don't have to rely on = "running the right software" as the basis for interoperability. Keith From jbates@brightok.net Tue Feb 8 11:02:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E1283A67D6; Tue, 8 Feb 2011 11:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mULKUE0d-RB3; Tue, 8 Feb 2011 11:02:11 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id D59E33A672E; Tue, 8 Feb 2011 11:02:10 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p18Ik9lA026314; Tue, 8 Feb 2011 12:46:09 -0600 (CST) Message-ID: <4D518F70.8070705@brightok.net> Date: Tue, 08 Feb 2011 12:46:08 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Templin, Fred L" References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net><4D50626 A .8020801@gmail.com> < 49 12B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.10206 06@ redpill-linpro.com> <4D51874F.9080803@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Keith Moore , "v6ops-bounces@ietf.org" , IPv6 Operations Subject: Re: [v6ops] when to tunnel vs. when to go native X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:02:11 -0000 On 2/8/2011 12:41 PM, Templin, Fred L wrote: > The ISP provides an Internet connectivity service to > its customers. But, there is nothing an ISP can do to > stop its customers from also obtaining alernate Internet > connectivity services through other providers. Couple > that with the fact that multi-access end systems are > common today, and will only become moreso going into > the future. I don't disagree that it's a value added service. It's just that, though. Value added and for a subset of consumers. For basic connectivity needs, IRON is not needed and would be problematic. Jack From dr@cluenet.de Tue Feb 8 11:02:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D78D3A680A for ; Tue, 8 Feb 2011 11:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZV09aEx0Zep9 for ; Tue, 8 Feb 2011 11:02:56 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 3653C3A67F5 for ; Tue, 8 Feb 2011 11:02:56 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id A35D21080CF; Tue, 8 Feb 2011 20:03:02 +0100 (CET) Date: Tue, 8 Feb 2011 20:03:02 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110208190302.GC28211@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <64800186-BC9B-4F76-8DBC-FDC13E017020@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <64800186-BC9B-4F76-8DBC-FDC13E017020@free.fr> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:02:57 -0000 On Tue, Feb 08, 2011 at 07:40:49PM +0100, Rémi Després wrote: > For rapid deployment of native IPv6 addresses where access network > aren't ready for IPv6 native routing, 6rd is AFAIK both done right AND sufficient. It's done as "right" as possible, indeed. Well, it could use some keepalive check to the 6RD BR, but that's my only gripe about it at the moment. :-) Any tunneling mechanisms HAS to be symmetrically in the hands of the ISP providing it in order to be supportable. 6RD is, anycast 6to4 isn't. Story told. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From Fred.L.Templin@boeing.com Tue Feb 8 11:14:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D9E3A6834; Tue, 8 Feb 2011 11:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.378 X-Spam-Level: X-Spam-Status: No, score=-6.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBUB+rZxsHeI; Tue, 8 Feb 2011 11:14:55 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 27C1E3A682C; Tue, 8 Feb 2011 11:14:54 -0800 (PST) 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 p18JEsYt010224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 13:14:59 -0600 (CST) 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 p18JEsw8019154; Tue, 8 Feb 2011 11:14:54 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p18JErUd019133 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 8 Feb 2011 11:14:54 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Tue, 8 Feb 2011 11:14:53 -0800 From: "Templin, Fred L" To: IPv6 Operations , "v6ops-bounces@ietf.org" Date: Tue, 8 Feb 2011 11:14:52 -0800 Thread-Topic: [v6ops] when to tunnel vs. when to go native Thread-Index: AcvHwsN9vgNnAcsvQLa7Q6Ltmo09qQAAG8Gw Message-ID: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net><4D5062 6 A .8020801@gmail.com> < 49 12B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.10 206 06@ redpill-linpro.com> <4D51874F.9080803@brightok.net> <4D518F70.8070705@brightok.net> In-Reply-To: <4D518F70.8070705@brightok.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] when to tunnel vs. when to go native X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:14:56 -0000 Hi Jack,=20 > On 2/8/2011 12:41 PM, Templin, Fred L wrote: > > The ISP provides an Internet connectivity service to > > its customers. But, there is nothing an ISP can do to > > stop its customers from also obtaining alernate Internet > > connectivity services through other providers. Couple > > that with the fact that multi-access end systems are > > common today, and will only become moreso going into > > the future. >=20 > I don't disagree that it's a value added service. It's just that,=20 > though. Value added and for a subset of consumers. >=20 > For basic connectivity needs, IRON is not needed and would be=20 > problematic. The ISP provides basic connectivity, yes. For an agreed price matched against a service level agreement, yes. But the ISPs cannot and should not dictate a sole provider lock-in to their customers. IRON is therefore *not* problematic, but rather a playing field leveler that promotes a healthy customer/provider inter-dependence instead of an unhealthy customer enslavement. Thanks - Fred fred.l.templin@boeing.com PS Please stop cutting out the meat of my messages; its not nice. And if someone is cooking this list, shame on you and please cut that out, too. > > -----Original Message----- > > From: Templin, Fred L=20 > > Sent: Tuesday, February 08, 2011 10:06 AM > > To: 'Roman.Arcea@orange.md'; Cameron Byrne > > Cc: v6ops-bounces@ietf.org; IPv6 Operations; Keith Moore > > Subject: when to tunnel vs. when to go native (was: RE:=20 > > [v6ops] Fwd: New Version Notificationfor=20 > > draft-troan-v6ops-6to4-to-historic-00) > >=20 > > Time out. > >=20 > > There is an aspect of this discussion that is being > > (I think unintentionally) glossed over, but that needs > > a deeper analysis. That being, when is it beneficial > > to tunnel vs. when to go native? > >=20 > > Tunneling is useful for much more than just incremental > > deployment of IPv6 over IPv4 networks. Tunneling is > > useful for mobility management, multihoming, traffic > > engineering, security (e.g., VPNs), and more. > >=20 > > But that said, no one is saying nor should it be > > advocated that there is no place for native IPv6. > > To the contrary, there are many instances in which > > native IPv6 makes far more sense than tunneled. For > > instance, major Internet service presences like google, > > yahoo, facebook, etc. (just to name a few) have no > > reason to tunnel. They aren't going anywhere, their > > services don't require strong encryption, and they're > > big enough that they can get their (multiple?) ISPs to > > advertise their PI IPv6 prefixes into the native IPv6 > > DFZ. Large enterprise networks fit the same description. > >=20 > > However, small- to medium-sized end user networks (EUNs) > > may not be big enough to pump their PI prefixes into > > their providers' routing systems, yet they may want to > > multi-home, to move around, to perform both out-bound > > and in-bound traffic engineering, to VPN into their home > > offices, etc. > >=20 > > The small- to mid-sized EUNs are therefore the realm > > where tunneling makes sense as a long-term solution. > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com = From jbates@brightok.net Tue Feb 8 11:22:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE5A3A6827; Tue, 8 Feb 2011 11:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.063 X-Spam-Level: X-Spam-Status: No, score=-3.063 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI9recwu9Cbs; Tue, 8 Feb 2011 11:22:07 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 2AF633A681B; Tue, 8 Feb 2011 11:22:07 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p18JM8Vs005529; Tue, 8 Feb 2011 13:22:08 -0600 (CST) Message-ID: <4D5197DF.2070401@brightok.net> Date: Tue, 08 Feb 2011 13:22:07 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Templin, Fred L" References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net><4D5062 6 A .8020801@gmail.com> < 49 12B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.10 206 06@ redpill-linpro.com> <4D51874F.9080803@brightok.net> <4D518F70.8070705@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "v6ops-bounces@ietf.org" Subject: Re: [v6ops] when to tunnel vs. when to go native X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:22:08 -0000 On 2/8/2011 1:14 PM, Templin, Fred L wrote: > But the ISPs cannot and should not dictate a sole > provider lock-in to their customers. IRON is therefore > *not* problematic, but rather a playing field leveler > that promotes a healthy customer/provider inter-dependence > instead of an unhealthy customer enslavement. > I agree. However, I'm only interested in an ISP deployment model, which is when to tunnel and when to go native. From an ISP perspective, Native is preferred and 6rd is second best. IRON isn't the appropriate solution to feed thousands/millions of home users their IPv6 access. What they do after I provide them basic connectivity is up to them. > > PS Please stop cutting out the meat of my messages; its not > nice. And if someone is cooking this list, shame on you > and please cut that out, too. > I always trim what I'm not referring to. Why duplicate what you have in another message if my response doesn't deal with it? Jack From moore@network-heretics.com Tue Feb 8 11:25:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5E23A67D6 for ; Tue, 8 Feb 2011 11:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GutEe3uX5qxj for ; Tue, 8 Feb 2011 11:25:33 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 4024F3A672E for ; Tue, 8 Feb 2011 11:25:33 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmtBy-0000zg-Lq; Tue, 08 Feb 2011 14:25:39 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-41-1058354931 From: Keith Moore In-Reply-To: Date: Tue, 8 Feb 2011 14:25:34 -0500 Message-Id: <469D9985-6FD4-49CB-83D6-D081DA1D550B@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> <4D515EE7.1080008@brightok.net> <4D516522.9050007@brightok.net> <4BF9DA98-DBD9-4658-A28A-C1463B3808C1@network-heretics.com> <4D518248.3000900@brightok.net> <9EFE9F0A-A210-4AAD-880B-1F3709C14EE4@network-heretics.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94082faf7e0c1623b8558b963d4f66c28f6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:25:34 -0000 --Apple-Mail-41-1058354931 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 8, 2011, at 1:33 PM, Cameron Byrne wrote: >>> work is broken until core networks fix pathing and peering issues. = End of story. Until that occurs, putting average joe on IPv6 is asking = them to have a horrible experience. >>=20 >> So, in summary: >>=20 >> a) IPv4 is broken both because of address scarcity and because = there's a large body of bad practice out there >> b) because IPv4 is broken, 6to4 is broken >> c) IPv6 is broken because it hasn't been well shaken down yet. >>=20 >=20 > You forgot that 6to4 is broken and therefore slows down IPv6 content > deployment and drives up ISP helpdesk calls. The IPv4 network is broken. Calls to ISP helpdesks about 6to4 not = working are a symptom of this brokenness. Keith --Apple-Mail-41-1058354931 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
work is broken until core = networks fix pathing and peering issues. End of story. Until that = occurs, putting average joe on IPv6 is asking them to have a horrible = experience.

So, in = summary:

a) IPv4 is = broken both because of address scarcity and because there's a large body = of bad practice out there
b) = because IPv4 is broken, 6to4 is broken
c) IPv6 is broken because it hasn't been well shaken down = yet.


You = forgot that 6to4 is broken and therefore slows down IPv6 = content
deployment and drives up ISP helpdesk calls.

The = IPv4 network is broken.  Calls to ISP helpdesks about 6to4 not = working are a symptom of this = brokenness.

Keith

= --Apple-Mail-41-1058354931-- From moore@network-heretics.com Tue Feb 8 11:30:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0833A682C for ; Tue, 8 Feb 2011 11:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iqi5tUdi-hu6 for ; Tue, 8 Feb 2011 11:30:48 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 32D003A680A for ; Tue, 8 Feb 2011 11:30:48 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmtH4-0000mB-L7; Tue, 08 Feb 2011 14:30:55 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <132A9FE8-6CA9-4ACE-A30B-40668FFB784F@nominum.com> Date: Tue, 8 Feb 2011 14:30:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0BA68B4C-1D22-41F9-BE59-1EDCE8EF94DB@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <4D514EAB.3070109@brightok.net> <0BDAB499-AAE2-432B-B7C7-C2F03744FC93@network-heretics.com> <2AD4DD41-50F9-4837-A33D-4E725323AA56@network-heretics.com> <132A9FE8-6CA9-4ACE-A30B-40668FFB784F@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9402ca39df60f88f8ed0e4a20322c2be12e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:30:49 -0000 On Feb 8, 2011, at 1:37 PM, Ted Lemon wrote: > On Feb 8, 2011, at 12:53 PM, Keith Moore wrote: >> So I think there's a huge benefit in leveraging the 6to4 support that = already exists in most hosts. But hey, native v6 is even better. >=20 > Unfortunately I think the number of people for whom this matters is = quite small, because it requires expertise to make it work. =20 It requires ISPs to do their jobs. It doesn't require expertise on the = part of the end users. =20 I have customers running applications that expect to be able to get to = network nodes using IPv6. Those customers are ordinary users, not = experts. =20 > Like it or not, the people we want to be using IPv6 are people like = my mom and dad, not people like you and me. =20 Who is this "we" you're referring to? The Internet is a tremendously diverse place. I don't know that I = believe in any notion of a typical user. Even if there were one today, = two years from now it would be different. Keith From Fred.L.Templin@boeing.com Tue Feb 8 11:35:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D443A683F; Tue, 8 Feb 2011 11:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlkGWr3VDyBP; Tue, 8 Feb 2011 11:35:43 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 0DEF53A683E; Tue, 8 Feb 2011 11:35:42 -0800 (PST) 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 p18JZnYl021316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 13:35:49 -0600 (CST) 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 p18JZnTv011866; Tue, 8 Feb 2011 13:35:49 -0600 (CST) 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 p18JZmaT011826 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 8 Feb 2011 13:35:49 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Tue, 8 Feb 2011 11:35:48 -0800 From: "Templin, Fred L" To: Jack Bates Date: Tue, 8 Feb 2011 11:35:47 -0800 Thread-Topic: [v6ops] when to tunnel vs. when to go native Thread-Index: AcvHxYe2Y67MoCkdRSes2ldYhfTgGQAAE7SQ Message-ID: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net><4D506 2 6 A .8020801@gmail.com> < 49 12B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4 .10 206 06@ redpill-linpro.com> <4D51874F.9080803@brightok.net> <4D518F70.8070705@brightok.net> <4D5197DF.2070401@brightok.net> In-Reply-To: <4D5197DF.2070401@brightok.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations , "v6ops-bounces@ietf.org" Subject: Re: [v6ops] when to tunnel vs. when to go native X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:35:44 -0000 Hi Jack,=20 > -----Original Message----- > From: Jack Bates [mailto:jbates@brightok.net]=20 > Sent: Tuesday, February 08, 2011 11:22 AM > To: Templin, Fred L > Cc: IPv6 Operations; v6ops-bounces@ietf.org > Subject: Re: [v6ops] when to tunnel vs. when to go native >=20 >=20 >=20 > On 2/8/2011 1:14 PM, Templin, Fred L wrote: > > But the ISPs cannot and should not dictate a sole > > provider lock-in to their customers. IRON is therefore > > *not* problematic, but rather a playing field leveler > > that promotes a healthy customer/provider inter-dependence > > instead of an unhealthy customer enslavement. > > >=20 > I agree. However, I'm only interested in an ISP deployment=20 > model, which=20 > is when to tunnel and when to go native. From an ISP=20 > perspective, Native=20 > is preferred and 6rd is second best. IRON isn't the=20 > appropriate solution=20 > to feed thousands/millions of home users their IPv6 access. I have already laid out the requirements that IRON satisfies and that others like 6rd do not begin to address. There are other aspects that I haven't even touched on, including tunnel path MTU assurance. Therefore, I question and disagree with your statement that 6rd is second-best. IRON is also beneficial to the customers even if an ISP network were to go to native IPv6; IRON tunnels over native IPv6 networks just as readily as it tunnels over native IPv4 networks. A third alternative is that the ISP network could do nothing at all and allow some 3rd party to stand up an IRON service that reaches through to the ISP's customers. In that case, the ISP incurs no costs whatsoever, but surrenders a control point that it could otherwise have exercised. Thanks - Fred fred.l.templin@boeing.com=20 =20 > What they do after I provide them basic connectivity is up to them. > > PS Please stop cutting out the meat of my messages; its not > > nice. And if someone is cooking this list, shame on you > > and please cut that out, too. > > >=20 > I always trim what I'm not referring to. Why duplicate what=20 > you have in=20 > another message if my response doesn't deal with it? >=20 >=20 > Jack > = From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Feb 8 12:24:29 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1519E3A684E for ; Tue, 8 Feb 2011 12:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQw8NMRDG0SG for ; Tue, 8 Feb 2011 12:24:28 -0800 (PST) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id 47D343A680E for ; Tue, 8 Feb 2011 12:24:28 -0800 (PST) Received: from 182-239-153-173.ip.adam.com.au ([182.239.153.173] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Pmu6y-0007ZV-0v; Wed, 09 Feb 2011 06:54:32 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 770493B336; Wed, 9 Feb 2011 06:54:31 +1030 (CST) Date: Wed, 9 Feb 2011 06:54:31 +1030 From: Mark Smith To: Ted Lemon Message-ID: <20110209065431.50a2ec5b@opy.nosense.org> In-Reply-To: <653820E8-8DE1-43D5-AD27-DA08E70939E0@nominum.com> References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <6B3B9302-48C6-406A-BAFC-2AC62ABB29AF@apple.com> <653820E8-8DE1-43D5-AD27-DA08E70939E0@nominum.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 20:24:29 -0000 On Tue, 8 Feb 2011 11:28:28 -0500 Ted Lemon wrote: > On Feb 8, 2011, at 11:22 AM, james woodyatt wrote: > > In this particular case, we can expect that happy-eyeballs implementations will more often than not close unused connection attempts in an orderly fashion, but hosts and networks get interrupted all the time in the real world, and exceptions will be frequent. I wouldn't want to be swimming against that tide. > > It sounds like you're saying CGN can't work. :) > > (Although, to be fair, I will reiterate that in the worst-case scenario happy eyeballs as currently documented presents no more load to CGN than non-happy-eyeballs, and in the usual case it presents less load.) > CGNs will have to be robust against this sort of thing anyway. As they maintain connection or traffic driven state, they'd be vulnerable to DoSes if they don't. I'd expect total active connections and possibly connection set up rate limits will be applied on a per downstream client basis. Regards, Mark. From brian.e.carpenter@gmail.com Tue Feb 8 12:32:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0115E3A6868 for ; Tue, 8 Feb 2011 12:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.587 X-Spam-Level: X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzebo6sTkQ+J for ; Tue, 8 Feb 2011 12:32:57 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 92B3F3A681E for ; Tue, 8 Feb 2011 12:32:57 -0800 (PST) Received: by fxm9 with SMTP id 9so6985766fxm.31 for ; Tue, 08 Feb 2011 12:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+aiGHQl65qjYzk/flqH69h3C/dz6tfgxzv44H3gxJiA=; b=V1BBE7MvdwSrYPnpE1VVXVYjs/UaJ17l7O0KXq8bm+PQTeuT3nUd267RpNI0d53V9g c4c0SZdtELdg7/Zc9u/OIWNDB7arEEUsxXpxCNGDUFR7vBhJ5mctl1ZaZnzZ9sRL6kPn 04/TdXaniGDAoW/iHvGbh7mZMM01V0DHgMDu4= 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=S8kk0RSQTBnaTsxKMiwbgc0sfJGq6Bw5K64R9KQL3bFScpVvo0nyvn8AxiA4BjtFMa oRDN4uEzFTg8rg8RVoj4e8u2W2Q2MFACdbeA0v9dkVAxi9p26qOU3zHoe7vK4Xxnjmd/ 2KqrQo8ivaob6T+texraLOhSmPkuImghZJxN4= Received: by 10.223.72.12 with SMTP id k12mr13883091faj.114.1297197184453; Tue, 08 Feb 2011 12:33:04 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id j12sm1924189fax.9.2011.02.08.12.32.56 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Feb 2011 12:32:59 -0800 (PST) Message-ID: <4D51A876.2020004@gmail.com> Date: Wed, 09 Feb 2011 09:32:54 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Erik Kline References: <4D514CBB.7010007@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 20:32:59 -0000 On 2011-02-09 03:11, Erik Kline wrote: > On 8 February 2011 14:01, Simon Perreault wrote: > >> On 2011-02-07 23:41, Cameron Byrne wrote: >>> Is it possible that happy eyeballs is not feasible to implement within >>> the short time frame that it may be useful? >> Even in a pure IPv6-only world, happy eyeballs would still be useful. >> When a name resolves to multiple addresses, trying them in parallel has >> advantages over trying them in sequence. >> > > Even is takes 2 years to get out there and broadly adopted by applications / > OSes, does anyone think that IPv4 will be virtually eliminated by the 2 year > mark? I suppose I could be (pleasantly) surprised, but... We've needed something like happy eyeballs for many years and we will continue needing it for, oh, let me take a SWAG, another ten years at least. I am in favour of adopting this and getting it out as Informational ASAP - it really isn't necessary to sweat over making it normative, because the real work is in getting it into half a dozen key operating systems. Brian From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Feb 8 12:34:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21483A6857 for ; Tue, 8 Feb 2011 12:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.362 X-Spam-Level: X-Spam-Status: No, score=-1.362 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92tLHPiqbMFU for ; Tue, 8 Feb 2011 12:34:55 -0800 (PST) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id 189863A681E for ; Tue, 8 Feb 2011 12:34:54 -0800 (PST) Received: from 182-239-153-173.ip.adam.com.au ([182.239.153.173] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PmuH1-0007wZ-LL; Wed, 09 Feb 2011 07:04:55 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id EB24D3B336; Wed, 9 Feb 2011 07:04:54 +1030 (CST) Date: Wed, 9 Feb 2011 07:04:54 +1030 From: Mark Smith To: Ted Lemon Message-ID: <20110209070454.7a1f353f@opy.nosense.org> In-Reply-To: <4E8CAF8B-4CB9-41CE-9880-1DB78C40EF7C@nominum.com> References: <4D5150AA.8050902@viagenie.ca> <4E8CAF8B-4CB9-41CE-9880-1DB78C40EF7C@nominum.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 20:34:56 -0000 On Tue, 8 Feb 2011 09:40:04 -0500 Ted Lemon wrote: > On Feb 8, 2011, at 9:18 AM, Simon Perreault wrote: > > IMHO, we need to decide whether we want to recommend happy eyeballs or > > not. There were concerns about it breaking determinism, breaking > > prioritization, etc. Are these issues "deal-breakers", or can happy > > eyeballs be modified to fix/mitigate them? > > Happy Eyeballs as written actually doesn't break determinism, because it prefers the means of connection that worked last time. I argued against this last night because I couldn't figure out a good way to implement it, but sometime last night it sunk in to me what problem the preference algorithm in Happy Eyeballs was meant to solve, and I realized that it isn't as hard to implement as I'd assumed (there's no need to implement host-wide state). > > I think you're right that we do need to decide whether to recommend Happy Eyeballs. I do not think there are any deal-breakers. I think there are a few tweaks needed to the draft before it's done, but we are on the right track. > It's worth noticing that a few transport layer protocols are or starting to look at doing this sort of thing "within" themselves, specifically SCTP and multipath-TCP - http://datatracker.ietf.org/wg/mptcp/charter/ So doing it across multiple protocol families and multiple transport protocols is only really a generalisation of that idea. I therefore think happy eyeballs is worth recommending. Regards, Mark. From Ted.Lemon@nominum.com Tue Feb 8 12:37:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F12793A6859 for ; Tue, 8 Feb 2011 12:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drODAjje0K4T for ; Tue, 8 Feb 2011 12:37:13 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id C42473A6835 for ; Tue, 8 Feb 2011 12:37:12 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTVGpgKkjzdui8/GHo+SK1SFUWWQ3qyqo@postini.com; Tue, 08 Feb 2011 12:37:20 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 86C5B1B83BC for ; Tue, 8 Feb 2011 12:37:19 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 670D6190052; Tue, 8 Feb 2011 12:37:19 -0800 (PST) (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; Tue, 8 Feb 2011 12:37:19 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <20110209065431.50a2ec5b@opy.nosense.org> Date: Tue, 8 Feb 2011 15:37:15 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <60EFD952-7D2F-4FD9-B08F-9D05BA18C325@nominum.com> References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <6B3B9302-48C6-406A-BAFC-2AC62ABB29AF@apple.com> <653820E8-8DE1-43D5-AD27-DA08E70939E0@nominum.com> <20110209065431.50a2ec5b@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1082) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 20:37:15 -0000 On Feb 8, 2011, at 3:24 PM, Mark Smith wrote: > CGNs will have to be robust against this sort of thing anyway. As they > maintain connection or traffic driven state, they'd be vulnerable to > DoSes if they don't. I'd expect total active connections and possibly > connection set up rate limits will be applied on a per downstream > client basis. Of course, functional CGN that doesn't produce random dropped = connections is essentially antithetical to DoS attack avoidance. So = the upshot of what you've said, with which I agree, is that CGN is not = going to be a satisfactory solution, and that we'd bloody well better be = able to offer IPv6 as an alternative. From Wesley.E.George@sprint.com Tue Feb 8 13:04:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E91E3A687A for ; Tue, 8 Feb 2011 13:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKI4tVdXEX3E for ; Tue, 8 Feb 2011 13:04:54 -0800 (PST) Received: from DB3EHSOBE002.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by core3.amsl.com (Postfix) with ESMTP id 028703A6857 for ; Tue, 8 Feb 2011 13:04:53 -0800 (PST) Received: from mail32-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.8; Tue, 8 Feb 2011 21:05:00 +0000 Received: from mail32-db3 (localhost.localdomain [127.0.0.1]) by mail32-db3-R.bigfish.com (Postfix) with ESMTP id B64A6188865C; Tue, 8 Feb 2011 21:05:00 +0000 (UTC) X-SpamScore: -52 X-BigFish: VS-52(zf7Izbb2dK936eK542N1418M98dN9371Pzz1202hzz8275dh1033ILz2fh2a8h668h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI Received: from mail32-db3 (localhost.localdomain [127.0.0.1]) by mail32-db3 (MessageSwitch) id 1297199100221991_21388; Tue, 8 Feb 2011 21:05:00 +0000 (UTC) Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.247]) by mail32-db3.bigfish.com (Postfix) with ESMTP id 28F211840051; Tue, 8 Feb 2011 21:05:00 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 8 Feb 2011 21:04:56 +0000 Received: from PDAWEH02.ad.sprint.com (PDAWEH02.corp.sprint.com [144.226.111.42]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p18L4fNC002950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Feb 2011 15:04:42 -0600 Received: from PDAWM12B.ad.sprint.com ([fe80::64c8:fd69:1029:79b0]) by PDAWEH02.ad.sprint.com ([2002:90e2:6f2a::90e2:6f2a]) with mapi id 14.01.0270.001; Tue, 8 Feb 2011 15:04:41 -0600 From: "George, Wes E [NTK]" To: Joel Jaeggli , Martin Millnert Thread-Topic: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 Thread-Index: AQHLx1p9ZCBm+cfEGkCTwUwWekcqTJP4CyRg Date: Tue, 8 Feb 2011 21:04:40 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E36726E@PDAWM12B.ad.sprint.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> In-Reply-To: <4D50E44F.60609@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.25] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0040_01CBC7A9.E3035D00" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: Keith, "v6ops@ietf.org" , Daniel Roesen , Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:04:55 -0000 ------=_NextPart_000_0040_01CBC7A9.E3035D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Joel Jaeggli Sent: Tuesday, February 08, 2011 1:36 AM > On 2/7/2011 1:29 PM, Cameron Byrne wrote: >> I already null route the anycast address because it cause a mess in >> my CGN/NAT tables ... since i use bogon space to my users they think >> 6to4 might work [WEG] So I think that one of the things in Brian's draft (or it was recommended on list and not integrated yet) is a recommendation to respond with unreachables to anything directed at the 6to4 Anycast block if you are blocking protocol 41 or otherwise doing something that would break 6to4, to at least give things trying to use 6to4 a fighting chance of realizing that it's broken and disabling it. Depending on your vendor and your config, you either will or will not respond with unreachables when you null route. I agree that we shouldn't expect you to make it work through NAT + bogons, but I think it's fair to expect that it doesn't fail silently, because then it contributes to that brokenness that everyone is worried about when they enable IPv6. > On Mon, 2011-02-07 at 11:44 -0800, Cameron Byrne wrote: >> Nope, and not interested since customers don't care about this 6to4 >> service. [WEG] Well, I distinctly remember threads on NANOG calling out more than one US mobile provider for blocking protocol 41 last year, whether they were doing it accidentally or on purpose... Clearly an exception and not the rule, but I don't buy "no one is using/cares". The same (customers don't care) could be said for IPv6 - as you said, customers care about Facebook, etc, not which protocol they use to get to it. Native IPv6 will eliminate the need for 6to4, but unfortunately we're not there yet, and there are too many cases where you can't control if your users turn on 6to4, either unconsciously because their *existing* device enables it by default, or consciously in order to compensate for the fact that real IPv6 isn't there yet. So right now, we need to make sure we contain the brokenness where it's not possible to support it, and eliminate the brokenness where it's possible to do so with relatively low effort, not simply ignore until Native IPv6 makes it go away. Deprecating or making 6to4 Historic might help in a tiny way with future devices (in the same way that draft-george might help improve IPv6 support), but it mostly changes nothing about existing installed base, which is coincidentally where the brokenness is most likely to exist. Wes George ------=_NextPart_000_0040_01CBC7A9.E3035D00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDITCCAx0CAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB8DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAyMDgyMTA0MzhaMCMGCSqGSIb3DQEJBDEWBBTSCsPZL5gG IUlOeeDo03EPMvFK5TBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjCBlwYJKwYB BAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJp bnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNl IElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJEAILMYGJoIGGMHgx EzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/Is ZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRo b3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYAsXFI+Z5rdoHXM2DG1B2dJXIj2CPqW NE5Fn7tCkbz4DpiTafRisEksO4CDR2qbHUXYrOD7W6pVjYyfDPlhR332H4OK77KPfjTGJbCaj45A sE0CzDcDoZV76uwfbgxLKdc99uUsYNhvZcqbH2kjqaiaEVftUb8VW6ZMtqoGqTpp4gAAAAAAAA== ------=_NextPart_000_0040_01CBC7A9.E3035D00-- From jbates@brightok.net Tue Feb 8 13:05:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D19753A688E for ; Tue, 8 Feb 2011 13:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.218 X-Spam-Level: X-Spam-Status: No, score=-3.218 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8+iGIVgfoQF for ; Tue, 8 Feb 2011 13:05:45 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id F02003A67F3 for ; Tue, 8 Feb 2011 13:05:44 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18L5hUW006425; Tue, 8 Feb 2011 15:05:43 -0600 (CST) Message-ID: <4D51B026.9030806@brightok.net> Date: Tue, 08 Feb 2011 15:05:42 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ted Lemon References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <6B3B9302-48C6-406A-BAFC-2AC62ABB29AF@apple.com> <653820E8-8DE1-43D5-AD27-DA08E70939E0@nominum.com> <20110209065431.50a2ec5b@opy.nosense.org> <60EFD952-7D2F-4FD9-B08F-9D05BA18C325@nominum.com> In-Reply-To: <60EFD952-7D2F-4FD9-B08F-9D05BA18C325@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:05:45 -0000 On 2/8/2011 2:37 PM, Ted Lemon wrote: > Of course, functional CGN that doesn't produce random dropped > connections is essentially antithetical to DoS attack avoidance. So > the upshot of what you've said, with which I agree, is that CGN is > not going to be a satisfactory solution, and that we'd bloody well > better be able to offer IPv6 as an alternative. Which in turn defeats the purpose of happy eyeballs. That's the problem. LSN is horrid. It will force people into IPv6 connectivity quickly to avoid the brokenness of LSN. In doing so, it defeats the necessity of happy eyeballs. In 2 years (when we'd expect a large enough deployment of happy eyeballs implementations), IPv4 will be isolated pockets of deadness. Jack From moore@network-heretics.com Tue Feb 8 13:12:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E96F3A6868 for ; Tue, 8 Feb 2011 13:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agrXrF0YXDHd for ; Tue, 8 Feb 2011 13:12:40 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id A13483A67F3 for ; Tue, 8 Feb 2011 13:12:40 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmurY-00085H-1K; Tue, 08 Feb 2011 16:12:40 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E36726E@PDAWM12B.ad.sprint.com> Date: Tue, 8 Feb 2011 16:12:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6DC6A648-5243-4259-BE2E-D25E17DF63C4@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> <54E900DC635DAB4DB7A6D799B3C4CD8E36726E@PDAWM12B.ad.sprint.com> To: "George, Wes E [NTK]" X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94020140a6d81d1d8641ef7abda138a1631350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: "v6ops@ietf.org" , Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:12:41 -0000 On Feb 8, 2011, at 4:04 PM, George, Wes E [NTK] wrote: > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Joel Jaeggli > Sent: Tuesday, February 08, 2011 1:36 AM >=20 >> On 2/7/2011 1:29 PM, Cameron Byrne wrote: >>> I already null route the anycast address because it cause a mess in=20= >>> my CGN/NAT tables ... since i use bogon space to my users they = think >>> 6to4 might work > [WEG] So I think that one of the things in Brian's draft (or it was = recommended on list and not > integrated yet) is a recommendation to respond with unreachables to = anything directed at the 6to4 > Anycast block if you are blocking protocol 41 or otherwise doing = something that would break 6to4, to > at least give things trying to use 6to4 a fighting chance of realizing = that it's broken and > disabling it. Depending on your vendor and your config, you either = will or will not respond with > unreachables when you null route. I agree that we shouldn't expect you = to make it work through NAT + > bogons, but I think it's fair to expect that it doesn't fail silently, = because then it contributes > to that brokenness that everyone is worried about when they enable = IPv6.=20 Blocking 41 breaks more than 6to4. If an operator really needs to = break 6to4, say because it is using CGN, I agree that returning ICMP = unreachable is probably the right thing to do. But the filter should = look deeper into the packet than the protocol number so that it only = filters 6to4-style tunneling and not configured tunnels. And breaking = 6to4 should be considered a nuclear option. It's far better to fix = it. > Deprecating or making > 6to4 Historic might help in a tiny way with future devices (in the = same way that draft-george might > help improve IPv6 support), but it mostly changes nothing about = existing installed base, which is > coincidentally where the brokenness is most likely to exist. It's also a Bad Idea to change existing practice, even for newly shipped = software/devices, without there being a suitable replacement. Granted = that several problems exist with 6to4, but at least they're identified, = and they can be addresses via various means. If you discard 6to4 in = favor of some other transition mechanism, you get to discover a new set = of problems with that mechanism and deal with those - putting operators = and users even further behind the curve than they are now. Keith From Ted.Lemon@nominum.com Tue Feb 8 13:19:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F423A683A for ; Tue, 8 Feb 2011 13:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 955gv-nELVvE for ; Tue, 8 Feb 2011 13:19:12 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 715D03A67F3 for ; Tue, 8 Feb 2011 13:19:12 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTVGzV5IVsSDUjoJbkRrutBqF/xFS+7Q1@postini.com; Tue, 08 Feb 2011 13:19:20 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D5D931B83B3 for ; Tue, 8 Feb 2011 13:19:17 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id BDEE0190052; Tue, 8 Feb 2011 13:19:17 -0800 (PST) (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; Tue, 8 Feb 2011 13:19:17 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4D51B026.9030806@brightok.net> Date: Tue, 8 Feb 2011 16:19:13 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <6B3B9302-48C6-406A-BAFC-2AC62ABB29AF@apple.com> <653820E8-8DE1-43D5-AD27-DA08E70939E0@nominum.com> <20110209065431.50a2ec5b@opy.nosense.org> <60EFD952-7D2F-4FD9-B08F-9D05BA18C325@nominum.com> <4D51B026.9030806@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:19:13 -0000 On Feb 8, 2011, at 4:05 PM, Jack Bates wrote: > Which in turn defeats the purpose of happy eyeballs. That's the = problem. LSN is horrid. It will force people into IPv6 connectivity = quickly to avoid the brokenness of LSN. In doing so, it defeats the = necessity of happy eyeballs. In 2 years (when we'd expect a large enough = deployment of happy eyeballs implementations), IPv4 will be isolated = pockets of deadness. If that turns out to be true, then the small effort spent on happy = eyeballs will be less valuable than we'd anticipated. If it turns out = not to be true, then the work on happy eyeballs will have been = worthwhile. History is not smiling on people who anticipated rapid = IPv6 ubiquity; I see no reason to assume that it will suddenly start = smiling in the next two years. From victor.kuarsingh@gmail.com Tue Feb 8 13:19:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4011B3A6882 for ; Tue, 8 Feb 2011 13:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMSjRhx2cskK for ; Tue, 8 Feb 2011 13:19:40 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 677C83A67F3 for ; Tue, 8 Feb 2011 13:19:40 -0800 (PST) Received: by gwb20 with SMTP id 20so2790670gwb.31 for ; Tue, 08 Feb 2011 13:19:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=HWpQUxL7fOtNBLFvPf0aZqniqA/jcA6lfK7Ei7DK6Lw=; b=LKTcXaTTA9CKCi4B8TqyA0oab1TGj7xq/CyDuR/r72xTFRmtGhVuAqMMb1HbFw3UnX XiARgMljWslio2D7KdWiJQbpJ8e3cMQRXk21izeoN2Bq+iZ27TNY5ZPixMDn/lBPzCuT Th0hrsifCPaIgC5JPsY27Lxr+LtQUYH46OjNs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; b=Ix3Jz2jT2UTFbjATc+AZ6bCNlP/xXRD+iE3Ex/cfTghTuQSiqlu0aNyQyLmCdvA6lE iHlTNAOgVvWjznbh9t6NuP5s5n6eVw3E2ax/nnFA/rnd0a8m/r1RX8P07SCgDMWfmfUy nb9MkqYcJEJz3k0sSKxMsQnwb3SsB0H3DLSW4= Received: by 10.236.108.167 with SMTP id q27mr34486068yhg.36.1297199963740; Tue, 08 Feb 2011 13:19:23 -0800 (PST) Received: from [192.168.100.149] ([67.224.83.162]) by mx.google.com with ESMTPS id j3sm4017066yha.7.2011.02.08.13.19.21 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Feb 2011 13:19:22 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Tue, 08 Feb 2011 16:25:26 -0500 From: Victor Kuarsingh To: Message-ID: Thread-Topic: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 In-Reply-To: <0BA68B4C-1D22-41F9-BE59-1EDCE8EF94DB@network-heretics.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:19:41 -0000 Ole, In general, I do not agree with the principle of deprecating 6to4 until such time as the alternative is more widely deployed (I.e. native IPv6 or other options which provide end customer access to IPv6). I think in general, although there are many issues, it's still viable for some form of IPv6 connectivity. Comments have been made on the list that suggest that we should wait a bit longer until we consider this action to move 6to4 to historic. Data points after World IPv6 Day may bring to light on how this performs. My other concern is that even if this is done, by the time deployed hardware/software (in homes now) actually get replace and/or updated to remove 6to4 operation it will be a long way off. I would rather spend the time fixing and/or helping 6to4 to run it's course (since it already out there) by making it work as best as possible while concentrating on getting native IPv6 to homes. Also as note, I agree with list comments that suggest we would more appropriately be targeting RFC3068 versus RFC3056. Regards, Victor K From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Feb 8 13:21:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD693A6880 for ; Tue, 8 Feb 2011 13:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dc1FdQtilL+O for ; Tue, 8 Feb 2011 13:21:09 -0800 (PST) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id 906F73A6890 for ; Tue, 8 Feb 2011 13:21:09 -0800 (PST) Received: from 182-239-153-173.ip.adam.com.au ([182.239.153.173] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Pmuzp-0001Fu-HB; Wed, 09 Feb 2011 07:51:13 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id E105B3B336; Wed, 9 Feb 2011 07:51:10 +1030 (CST) Date: Wed, 9 Feb 2011 07:51:10 +1030 From: Mark Smith To: Jack Bates Message-ID: <20110209075110.280c08c6@opy.nosense.org> In-Reply-To: <4D51B026.9030806@brightok.net> References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <6B3B9302-48C6-406A-BAFC-2AC62ABB29AF@apple.com> <653820E8-8DE1-43D5-AD27-DA08E70939E0@nominum.com> <20110209065431.50a2ec5b@opy.nosense.org> <60EFD952-7D2F-4FD9-B08F-9D05BA18C325@nominum.com> <4D51B026.9030806@brightok.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:21:10 -0000 On Tue, 08 Feb 2011 15:05:42 -0600 Jack Bates wrote: > > > On 2/8/2011 2:37 PM, Ted Lemon wrote: > > Of course, functional CGN that doesn't produce random dropped > > connections is essentially antithetical to DoS attack avoidance. So > > the upshot of what you've said, with which I agree, is that CGN is > > not going to be a satisfactory solution, and that we'd bloody well > > better be able to offer IPv6 as an alternative. > > > Which in turn defeats the purpose of happy eyeballs. That's the problem. > LSN is horrid. It will force people into IPv6 connectivity quickly to > avoid the brokenness of LSN. In doing so, it defeats the necessity of > happy eyeballs. In 2 years (when we'd expect a large enough deployment > of happy eyeballs implementations), IPv4 will be isolated pockets of > deadness. > It still provides benefits in a pure IPv6 scenario. Mobile and multi-homed hosts are becoming common (i.e. smartphones, laptops etc.). At any time, there may be multiple possible avenues for successful connectivity to a destination (e.g. via active wired, wifi and 3g interfaces). Trying all of them in parallel, rather than sequentially, provides the best chance of success within a shorter time frame. I'm reminded a bit of the John Gilmore quote - "The Net interprets censorship as damage and routes around it." It seems to me that networked application developers have somewhat similar motives. Their fundamental goal and motive is to have their application communicate, so if there is a way for that to happen, they'll pursue mechanisms within their applications that will provide it. NAT traversal mechanisms like Skype's supernode model, or using HTTP as a substrate for more general communications than pure HTML are examples. These mechanisms are better placed lower in both the software and network stack so they are more widely available, re-implemented far less often, likely to be less buggy through far more common use and will be more predictable to troubleshoot. For those reasons I'm glad to see SCTP is one of the candidate transport protocols in the happy eyeballs draft. Regards, Mark. From brian.e.carpenter@gmail.com Tue Feb 8 13:25:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34A783A6880 for ; Tue, 8 Feb 2011 13:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.588 X-Spam-Level: X-Spam-Status: No, score=-103.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gpVQNT2Dgwk for ; Tue, 8 Feb 2011 13:25:57 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id CAB4A3A687D for ; Tue, 8 Feb 2011 13:25:56 -0800 (PST) Received: by fxm9 with SMTP id 9so7037744fxm.31 for ; Tue, 08 Feb 2011 13:26:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Si/3pIghe8dd7b0LgLwHLshTbTSwn/gEf/DxgqG7wYg=; b=TmHGuUenJnRmZ33edasUVE0jLt4qTn/ml5uENUq1kFenaR08Gz4QYvJeAysetlcz3A ied1zBEkqeeNmfO7BSz7C7AvESH/phQj5/NUU8R+qK3PEbN65v/PRfW1nCLuoTIHlw7r ccSTF7hhcHWObORW+3sfpfbZ5c5H6EDEsAdoU= 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=qtNQb3XJNWutfFeBvp77RMPk65MGZEcspQpQ7roZlEheOUnmHPRC6MqLCBYI6ZhNs0 JC12LiMp/hBvsXQImxV9gxV6Ib12yvNx+arbu/sHax5iW4fVgwjNPsMNKH6AmYBNq80m xZPutO9AhuoU18KPJC19Da2A/xmW4uHpHXbdQ= Received: by 10.223.86.13 with SMTP id q13mr3889080fal.53.1297200363809; Tue, 08 Feb 2011 13:26:03 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 17sm1945891far.43.2011.02.08.13.25.58 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Feb 2011 13:26:00 -0800 (PST) Message-ID: <4D51B4E4.1070405@gmail.com> Date: Wed, 09 Feb 2011 10:25:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Martin Millnert References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <1297162751.4205.42.camel@shakira.millnert.se> In-Reply-To: <1297162751.4205.42.camel@shakira.millnert.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:25:59 -0000 I hesitate to make this thread longer, especially since I'm deleting most of it unread, but this one is nice and technical, so... On 2011-02-08 23:59, Martin Millnert wrote: > Ole, > > On Tue, 2011-02-08 at 10:14 +0100, Ole Troan wrote: >> if the draft can achieve that: >> - CPE and hosts vendors stop enabling 6to4 by default Although my own draft isn't directed at vendors, I have added this point. >> - no-one advertises 6to4 AAAA records in DNS As others have said, there may be cases where an AAAA is OK, but my draft will contain a strong warning about this. >> - 6to4 is put at the absolute bottom (with Teredo) in the SAS/DAS >> algorithms. This belongs in the 3484bis discussion over in 6man. >> - people stop considering 6to4 as a valid transitioning mechanism; I've always hated the word "transition" anyway - we had to use it in RFC 3056 because we were in the ngTRANS working group. So I agree, but I can't control what people consider... >> there are too many choices already. > > The first (and maybe 3rd) point seems to be the most potent ones to me, > because of the relative few orgs who have some form of ability of making > this happen on a lot of hosts at the same time. > > But the important thing to figure out at this point, IMO, is: would they > disable it on running hosts? Eg, would host stack vendors flip 6to4 > default off on running hosts today (there are a few) given this drafts > existence? My support of this draft must follow the answer to that > question. > > (I seem to remember DNS to well-known addresses being deprecated but > still used by one of the vendors.) Given the number of places where 1.1.1.0/24 is in active use, I think we know the power of IETF documents to control reality :-( Brian From dr@cluenet.de Tue Feb 8 13:28:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BEDC3A6835 for ; Tue, 8 Feb 2011 13:28:16 -0800 (PST) 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.053, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9zE1d8+TVE0 for ; Tue, 8 Feb 2011 13:28:15 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id DE2403A67D4 for ; Tue, 8 Feb 2011 13:28:14 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id D81521080E7; Tue, 8 Feb 2011 22:28:21 +0100 (CET) Date: Tue, 8 Feb 2011 22:28:21 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110208212821.GA8815@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> <54E900DC635DAB4DB7A6D799B3C4CD8E36726E@PDAWM12B.ad.sprint.com> <6DC6A648-5243-4259-BE2E-D25E17DF63C4@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6DC6A648-5243-4259-BE2E-D25E17DF63C4@network-heretics.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:28:16 -0000 On Tue, Feb 08, 2011 at 04:12:36PM -0500, Keith Moore wrote: > If an operator really needs to break 6to4, say because it is using CGN, > I agree that returning ICMP unreachable is probably the right thing to do. Wow, we finally agree on something. :-) > But the filter should look deeper into the packet Which is something that might have legal implications. > than the protocol number so that it only filters 6to4-style tunneling > and not configured tunnels. The scenario which is our (residential ISPs forced to deploy some form of LSN) focus would be packets sourced by customers egress towards 6to4 anycast relays. Those packets should be easily recognizable by checking for destination IP 192.88.99.1. Any packet destined to that IP should trigger an ICMP unreachable message back to the sender, no matter what protocol is used (we want to avoid "alive" checks going false positive). > And breaking 6to4 should be considered a nuclear option. It breaks anyway. We just look for ways to break it more gracefully, read: don't have blackholing but give the 6to4 endpoint a chance to notice that 6to4 won't work. > It's far better to fix it. Too late. IPv4 depletion is right here. Not that I like it as an engineer, but we have to face operational realities. Sticking the head into the sand, ignoring the problems ahead, is exactly what has put us into this position in the first place. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From moore@network-heretics.com Tue Feb 8 13:28:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D94D3A683A for ; Tue, 8 Feb 2011 13:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-OYGmqgsSfc for ; Tue, 8 Feb 2011 13:28:55 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 526C23A67F3 for ; Tue, 8 Feb 2011 13:28:55 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Pmv7M-00080T-7Q; Tue, 08 Feb 2011 16:29:01 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: <1A32BA6A-F803-4231-B7C2-9C88E55A79E4@free.fr> Date: Tue, 8 Feb 2011 16:28:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <20562C47-24F4-4AB4-8A8B-6F56145B881B@network-heretics.com> References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4D5162E4.1020606@redpill-linpro.com> <20110208170421.GW44800@Space.Net> <1A32BA6A-F803-4231-B7C2-9C88E55A79E4@free.fr> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94097d4483760c963a6df46b70e5db1b135350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:28:56 -0000 On Feb 8, 2011, at 1:33 PM, R=E9mi Despr=E9s wrote: > IMHO: > - 6to4 disabled by default is a clear and *necessary* message I'm not at all convinced of its necessity. I still think it's a dubious = idea, because it will break compatibility with things that currently = work. Keith From jbates@brightok.net Tue Feb 8 13:30:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31AB3A6880 for ; Tue, 8 Feb 2011 13:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2f595OmXMTb for ; Tue, 8 Feb 2011 13:30:01 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 1086B3A6835 for ; Tue, 8 Feb 2011 13:30:01 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18LU1gW012991; Tue, 8 Feb 2011 15:30:01 -0600 (CST) Message-ID: <4D51B5D8.3060707@brightok.net> Date: Tue, 08 Feb 2011 15:30:00 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ted Lemon References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <6B3B9302-48C6-406A-BAFC-2AC62ABB29AF@apple.com> <653820E8-8DE1-43D5-AD27-DA08E70939E0@nominum.com> <20110209065431.50a2ec5b@opy.nosense.org> <60EFD952-7D2F-4FD9-B08F-9D05BA18C325@nominum.com> <4D51B026.9030806@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:30:01 -0000 On 2/8/2011 3:19 PM, Ted Lemon wrote: > On Feb 8, 2011, at 4:05 PM, Jack Bates wrote: >> Which in turn defeats the purpose of happy eyeballs. That's the >> problem. LSN is horrid. It will force people into IPv6 connectivity >> quickly to avoid the brokenness of LSN. In doing so, it defeats the >> necessity of happy eyeballs. In 2 years (when we'd expect a large >> enough deployment of happy eyeballs implementations), IPv4 will be >> isolated pockets of deadness. > > If that turns out to be true, then the small effort spent on happy > eyeballs will be less valuable than we'd anticipated. If it turns > out not to be true, then the work on happy eyeballs will have been > worthwhile. History is not smiling on people who anticipated rapid > IPv6 ubiquity; I see no reason to assume that it will suddenly start > smiling in the next two years. > Money. It's all about the money. That is why IPv6 has not even had market pressure until recently. Don't get me wrong. I appreciate the work on happy eyeballs, and it's still not a bad idea to push. If we don't need it, we will all be happy. If we do need it, we'll be thankful for it being there. Jack From dr@cluenet.de Tue Feb 8 13:31:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026B73A686A for ; Tue, 8 Feb 2011 13:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw7cSNuv6s5V for ; Tue, 8 Feb 2011 13:31:54 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 25CCA3A6835 for ; Tue, 8 Feb 2011 13:31:54 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 79B65108099; Tue, 8 Feb 2011 22:32:01 +0100 (CET) Date: Tue, 8 Feb 2011 22:32:01 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110208213201.GB8815@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D50626A.8020801@gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:31:55 -0000 On Tue, Feb 08, 2011 at 10:21:46AM +1300, Brian E Carpenter wrote: > (a) technically wrong, because it reclassifies RFC 3056, and the one that > does harm is RFC 3068; Agreed. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From moore@network-heretics.com Tue Feb 8 13:35:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB7AC3A686A for ; Tue, 8 Feb 2011 13:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JicJpcPcmjLU for ; Tue, 8 Feb 2011 13:35:05 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id CA2373A6835 for ; Tue, 8 Feb 2011 13:35:04 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmvDL-0002iu-K6; Tue, 08 Feb 2011 16:35:12 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110208185049.GB28211@srv03.cluenet.de> Date: Tue, 8 Feb 2011 16:35:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940fd2793b514cbf65f17c0082e68610547350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:35:05 -0000 On Feb 8, 2011, at 1:50 PM, Daniel Roesen wrote: > On Tue, Feb 08, 2011 at 08:59:42AM -0500, Keith Moore wrote: >> Well, it seems to me that 6to4 is yet another thing that users want = to do with CGN, >=20 > The amount of users who "want to do 6to4" you can search for with a > magnifier glass. >=20 > If anything, people want to "have IPv6". Most people don't understand their requirements in terms of "want to do = 6to4" or "want IPv6". They want their applications to work well. They = want to be able to talk to the hosts which they need to talk to, = regardless of whether those hosts speak v4, v6, or both. There's a huge = variety of different specific wants and needs under that description, = nearly all of which can be met by "please send my packets intact to the = addresses I specify, and please deliver packets addressed to my hosts". = If you start trying to justify some users' needs as more important than = others, you end up in a rat hole very quickly.=20 > Global anycast 6to4 is a problem, not a solution. That mentality is the problem. I think the message needs to go out very clearly to users is this: If your IPv6 access doesn't work, it's probably because your ISP (a) = didn't plan ahead for v6 deployment and instead (b) imposed CGN on you. = You should find another ISP. Keith From jbates@brightok.net Tue Feb 8 13:36:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E773A6835 for ; Tue, 8 Feb 2011 13:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGKOUEF4Hp5x for ; Tue, 8 Feb 2011 13:36:25 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 451333A6891 for ; Tue, 8 Feb 2011 13:36:25 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p18LaPlI010450; Tue, 8 Feb 2011 15:36:25 -0600 (CST) Message-ID: <4D51B758.8060802@brightok.net> Date: Tue, 08 Feb 2011 15:36:24 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Smith References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <6B3B9302-48C6-406A-BAFC-2AC62ABB29AF@apple.com> <653820E8-8DE1-43D5-AD27-DA08E70939E0@nominum.com> <20110209065431.50a2ec5b@opy.nosense.org> <60EFD952-7D2F-4FD9-B08F-9D05BA18C325@nominum.com> <4D51B026.9030806@brightok.net> <20110209075110.280c08c6@opy.nosense.org> In-Reply-To: <20110209075110.280c08c6@opy.nosense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:36:26 -0000 On 2/8/2011 3:21 PM, Mark Smith wrote: > It still provides benefits in a pure IPv6 scenario. Mobile and > multi-homed hosts are becoming common (i.e. smartphones, laptops etc.). > At any time, there may be multiple possible avenues for successful > connectivity to a destination (e.g. via active wired, wifi and 3g > interfaces). Trying all of them in parallel, rather than sequentially, > provides the best chance of success within a shorter time frame. Where is this provided for in the draft? I keep hearing people state things about happy eyeballs that don't appear to be in the draft. The draft seems to support connecting to an IPv4 address and an IPv6 address and seeing which works. It doesn't appear to support connecting out every combination of IPv6 destination/Source combination. Jack From brian.e.carpenter@gmail.com Tue Feb 8 13:40:58 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E3633A689B for ; Tue, 8 Feb 2011 13:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmYc10e7IhZP for ; Tue, 8 Feb 2011 13:40:57 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id EFD8A3A689E for ; Tue, 8 Feb 2011 13:40:56 -0800 (PST) Received: by fxm9 with SMTP id 9so7052848fxm.31 for ; Tue, 08 Feb 2011 13:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OFa7BnvZyJlDjsRcK+Wt+35nSGmwLG3FfqN6t6cHVyE=; b=WjkOaU2nwScKTMY/Y5lAZGmuAfuSgyAAI87bAV7YBV25V6VCMFDxHN9irPBJLCqnTq 9HZw/H03KoO0AGjpvrIqx/5yr7E5M8mWWXzykwrTGP7dntuz95WQTJQkUnJwVNVAZ5om mDZ/V21x8Epkqb+2CRGQD3YLKX4icAKcWOHqY= 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=LancAVm/XfwCq5J+3PkPV2dRTIaqtYTjUaBBEQqZyNq9Po4EZzmSUbSHM6LBXHqTP5 xzrzEXZlN0MYgqcQU6ppwGGzpa02tTjDdpWttLM+u1wXow0Zsbh1Z+Z0YM3/nYDMPeBF 8fcXMzUaF8yADD5Kfdqj47AAvzYpL38cxKnnA= Received: by 10.223.83.11 with SMTP id d11mr465599fal.37.1297201264225; Tue, 08 Feb 2011 13:41:04 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 5sm1954066fak.47.2011.02.08.13.41.00 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Feb 2011 13:41:02 -0800 (PST) Message-ID: <4D51B869.5060700@gmail.com> Date: Wed, 09 Feb 2011 10:40:57 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Keith Moore References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> In-Reply-To: <4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:40:58 -0000 On 2011-02-09 02:30, Keith Moore wrote: > On Feb 8, 2011, at 4:14 AM, Ole Troan wrote: > >> Brian, >> >>>>> I just posted the following draft suggesting that we move the 6to4 documents to historic. >>>> I think 3056 is harmless enough as it is, provided connectivity to >>>> "non-6to4" IPv6 is not happening (not *at all*, since you can't control >>>> the return path even if the outgoig relay is sane). >>>> >>>> 3068 is where the breakage comes from. >>>> >>>> 3056 with "only used for packets going to 2002: addresses, sourced from >>>> 2002: addresses" is useful. >>> Yes, and this why (when someone first proposed solving this problem >>> by telling people to STOP DOING THAT when they don't even know they're >>> doing it) I started work on the draft-carpenter-v6ops-6to4-teredo-advisory >>> draft. I strongly believe that's a much better use of IETF time and >>> money than reclassifying RFC 3068 to Historic. And there is no reason >>> to reclassify RFC 3056, because it isn't the one causing problems. >>> >>> So, this draft is >>> (a) technically wrong, because it reclassifies RFC 3056, and the one that >>> does harm is RFC 3068; >> 6to4 model 1 is not (and has never been) deployed (basically recreates the 6bone). > > Incorrect on both counts. Keith, I agree that this does not recreate the 6bone, although I do see why Ole says that. But can you cite specific examples of managed non-unicast deployment of 6to4? > >> 6to4 model 2, even with a consenting forward relay suffers the same issues on the reverse path. Of course. That's one reason that I wrote my draft. >> in my view 6to4 is not salvageable. But who's trying to salvage it? We have to *live* with anycast 6to4, probably for some years to come. That's the main reason I wrote my draft - not to boost anycast 6to4, but to make it tolerable. > > Perhaps that's because you haven't tried to identify solutions? it is possible, for instance, to identify and marginalize broken relay routers. To be honest, that's hard - unless you want to start a major project, with probes installed all around the world, to detect, name and shame broken relays. My hope is that we can publish advice that will cause ISPs to do the right thing; that isn't a golden bullet, but at least it's a finite job. Also - don't lose my point that the problem here is RFC 3068 and if we're going to deprecate anything, it should be that. >>> (b) wrong process-wise (RFC 2026 section 4.2.4), because it hasn't been >>> superseded and is in widespread use so cannot be called obsolete; >> from the same paragraph: "or is for any other reason considered to be obsolete is >> assigned to the "Historic" level." >> >> I think we can equate deprecating 6to4 to deprecating NAT-PT. it is harmful to IPv6 deployment. There's a big difference - at the time NAT-PT was deprecated, it wasn't in any signifcant use and could be considered a sleeping RFC with no operational impact. RFC 3068 isn't sleeping and I don't see how something so widely deployed can be deemed osbolete. Problematic, yes, but we don't have a "Problematic" status > 6to4 is not harmful to IPv6 deployment. ISPs that break IPv4 are harmful to IPv6 deployment. Oh, let's not have that argument. >>> (c) not constructive, because it doesn't offer solutions; >> the draft requests 6to4 to be deprecated, it is not the place to offer solutions. >> I think the "problem" 6to4 solves is miniscule. it provides a mechanism for us techies to play with IPv6. That's not quite what I meant. To be constructive, we need to advise operators to deal with reality: there's a lot of RFC 3068 out there. > 6to4 provides a way for anyone with any properly working IPv4 connect to connect to any IPv6 host. That's a huge win. It eliminates one of the barriers toward IPv6 acceptance by providing a means for universal access to IPv6 over any properly working IPv4 connection. > >> the solution is that the end user's service provider enables IPv6. 100% agree, of course, but that is another topic entirely. > Internet wide tunneling technologies specifically designed to bypass the underlaying infrastructure are hard to make work. I can't think of a single example where we have technology that makes that work well, supporting all the requirements that Fred listed. True. 6to4 has always been described as an interim solution. >> >>> (d) distracting us from useful work. >> 6to4 is what is distracting us. having to fix brokenness triggered by 6to4. Operators have to do that anyway. Passing a law against 6to4 won't change that; giving advice to operators may help them. That's why I plan to focus on my draft instead of Ole's... EOT Brian > > No, 6to4 is not broken. 6to4 is just sending IP packets and expecting them to get to the hosts associated with their destination addresses intact. > > The network is broken because of many brain damaged practices in place for other reasons, and 6to4 is one of many things suffering because of it. > > (I sometimes suspect that 6to4 is also suffering because some operators see it as an end-run around them, so they don't mind implementing measures that penalize it. But that's not a problem with 6to4....) > >>> Note that I am *not* trying to unnaturally prolong the life of 6to4 or >>> Anycast 6to4. A good way to get rid of them is for all ISPs to deploy IPv6, >>> for example. >> and until that happens (SP deploys IPv6), IPv6 deployment will not happen. 6to4 does not in any way accelerate IPv6 deployment. > > Completely incorrect. See above. > > I think the statement in a nutshell is this: as long as operators insist on seeing 6to4 as a 'problem' rather than a way to provide their customers good service and a useful transition tool, they're going to keep sabotaging it. By doing so they're actually impairing deployment of IPv6. > > Keith > > From fred@cisco.com Tue Feb 8 13:41:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE873A686A for ; Tue, 8 Feb 2011 13:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.424 X-Spam-Level: X-Spam-Status: No, score=-110.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVMHoJVuvSxl for ; Tue, 8 Feb 2011 13:41:25 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D393F3A67F3 for ; Tue, 8 Feb 2011 13:41:24 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP9GUU2rR7Hu/2dsb2JhbAClOnOhTpsxhVoEhHuGb4Mu Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Feb 2011 21:41:32 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p18LfRep009067; Tue, 8 Feb 2011 21:41:32 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Tue, 08 Feb 2011 13:41:32 -0800 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Tue, 08 Feb 2011 13:41:32 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D5154E1.60000@brightok.net> Date: Tue, 8 Feb 2011 13:41:18 -0800 Message-Id: <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:41:25 -0000 On Feb 8, 2011, at 6:36 AM, Jack Bates wrote: > On 2/7/2011 10:11 PM, Ted Lemon wrote: >> I've already stated a preference for a non-heuristic solution, where = you just try everything at once. >=20 > The problem with that outside of server load is the IPv4 CGN load as = we move into a more IPv6 world. I haven't had time to fully read the = draft, but I do hope that it properly closes all channels it won't use = for the sake of CGN tables. To my understanding, it does; it closes the relevant socket or = sub-socket, which results in a RST. That said, imagine it didn't. The Happy Eyeballs model would result in a = SYN Attack, which is to say that the receiving host would see more SYNs = than sessions it actually used. That would have the effect of consuming = TCB slots unproductively. We solved SYN attacks a long time ago. Most if not all host = implementations maintain a doubly linked list of TCBs; when a datagram = is handed to a TCB, the TCB is removed from the list and enqueued at the = end. Net effect, the TCB at the head of the list is the least recently = used TCB. In the event that the system runs out of TCBs and receives a = new SYN, it removes and re-uses the TCB at the head of the list. Voila, = SYN attacks are now ineffective. And by the way, this is consistent with the way many http/https services = work. If you use a pipelined TCP, rather than close a session (FIN, = FIN-ACK, ACK) or drop it (FIN, RST), they simply leave it open. If the = web application comes back with another GET, so be it, and if not, the = TCB eventually gets subsumed by the SYN Attack logic. I don't see the down side of Happy Eyeballs in this context, even if it = doesn't close the redundant sessions.= From jbates@brightok.net Tue Feb 8 13:49:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52DDC3A687F for ; Tue, 8 Feb 2011 13:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.221 X-Spam-Level: X-Spam-Status: No, score=-3.221 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3Ll3ekAcbN4 for ; Tue, 8 Feb 2011 13:49:19 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id EA07D3A6835 for ; Tue, 8 Feb 2011 13:49:18 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p18LnPCs013861; Tue, 8 Feb 2011 15:49:25 -0600 (CST) Message-ID: <4D51BA64.3080801@brightok.net> Date: Tue, 08 Feb 2011 15:49:24 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> In-Reply-To: <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:49:20 -0000 On 2/8/2011 3:41 PM, Fred Baker wrote: > I don't see the down side of Happy Eyeballs in this context, even if it doesn't close the redundant sessions. LSN in-betweens may not be so friendly. They will probably establish connection limits, and start failing connections when those limits are reached. This would pose problems for happy eyeballs if it doesn't properly handle connections. Which as previously stated, the discussed implementation models current do send RST. Jack From dr@cluenet.de Tue Feb 8 13:58:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6C83A6893 for ; Tue, 8 Feb 2011 13:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMMkPTZ1aOLL for ; Tue, 8 Feb 2011 13:58:48 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 1309E3A686A for ; Tue, 8 Feb 2011 13:58:48 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 716B1108094; Tue, 8 Feb 2011 22:58:55 +0100 (CET) Date: Tue, 8 Feb 2011 22:58:55 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110208215855.GC8815@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:58:49 -0000 On Tue, Feb 08, 2011 at 01:41:18PM -0800, Fred Baker wrote: > I don't see the down side of Happy Eyeballs in this context, even if > it doesn't close the redundant sessions. I'm not really into TCP SYN attack mitigation strategies, but from a LSN scenario perspective, it would tie up (LSN-)central resources. That is: NAT table entries and - possibly worse - outside ports. Every open or half open TCP connection would require a port mapped on the NAT outside, and this is a somewhat critical resource pool. There isn't much (well/publicly known) experience about that yet. What we _do_ know is that we want to ideally avoid short-living superfluous NAT sessions (impacts connection setup rate scaling on LSN) and reallyreally avoid a lot of long-living idle sessions binding session table entries AND outside LSN pool port numbers. They way I understand H.E. we cannot avoid the short-living "probe" connections (it's the basic operating model). But we need to make sure that any implementation really closes off all unused connections properly so session/port resources are freed up again as quickly as possible. How big the problem would be is difficult to guesstimate. Best regards, Daniel -- -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From moore@network-heretics.com Tue Feb 8 14:27:35 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340E53A6891 for ; Tue, 8 Feb 2011 14:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LqkKTF6zolL for ; Tue, 8 Feb 2011 14:27:34 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 4EBA03A68B7 for ; Tue, 8 Feb 2011 14:27:34 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Pmw28-0004N3-TS; Tue, 08 Feb 2011 17:27:41 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D51B4E4.1070405@gmail.com> Date: Tue, 8 Feb 2011 17:27:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <1297162751.4205.42.camel@shakira.millnert.se> <4D51B4E4.1070405@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9408cc0aa828cb4dad203e927e62cdbcb7a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:27:35 -0000 On Feb 8, 2011, at 4:25 PM, Brian E Carpenter wrote: > I hesitate to make this thread longer, especially since I'm deleting > most of it unread, but this one is nice and technical, so... >=20 > On 2011-02-08 23:59, Martin Millnert wrote: >> Ole, >>=20 >> On Tue, 2011-02-08 at 10:14 +0100, Ole Troan wrote: >>> if the draft can achieve that: >>> - CPE and hosts vendors stop enabling 6to4 by default >=20 > Although my own draft isn't directed at vendors, I have added > this point. I think it's premature to stop enabling 6to4 by default. =20 The appropriate date to start disabling 6to4 by default is approximately = the date at which operators' groups commit to lighting up native v6 and = providing it to their customers over the same interfaces/links over = which they currently provide v4. If operators' groups would commit on behalf of their members to a date = for doing that, I would support publishing that date in an RFC and = recommending that implementations shipped after that date disable 6to4 = by default. Keith From fred@cisco.com Tue Feb 8 14:31:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E10C3A68CD for ; Tue, 8 Feb 2011 14:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LY8rkkB2V14 for ; Tue, 8 Feb 2011 14:31:20 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 5FBCC3A68BC for ; Tue, 8 Feb 2011 14:31:20 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHxSUU2rR7H+/2dsb2JhbAClPnOhP44qAY0NhVoEhHuGb4Mu Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2011 22:31:28 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p18MVNPV025607; Tue, 8 Feb 2011 22:31:28 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Tue, 08 Feb 2011 14:31:28 -0800 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Tue, 08 Feb 2011 14:31:28 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <20110208215855.GC8815@srv03.cluenet.de> Date: Tue, 8 Feb 2011 14:31:13 -0800 Message-Id: <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> <20110208215855.GC8815@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:31:21 -0000 On Feb 8, 2011, at 1:58 PM, Daniel Roesen wrote: > They way I understand H.E. we cannot avoid the short-living "probe" > connections (it's the basic operating model). But we need to make sure > that any implementation really closes off all unused connections > properly so session/port resources are freed up again as quickly as > possible. How big the problem would be is difficult to guesstimate. No problem. =20 Before replaying to Jack's previous message, I verified that I knew what = I was talking about. I have a largish number of sites that I monitor = daily, and have a little script that does that. I took said list of = sites, cleared my web cache, started tcpdump, opened each of those URLs, = closed tcpdump, and then did a bit of analysis. In the following, = stealth-10-32-244-222.cisco.com is my computer, which is a Mac running = MacOSX 10.6.6; the browser I used was Google Chrome. I have 239 TCP sessions in total, some of which were IPv4 and some were = IPv6, and some of which were pretty short and some were pretty long. I saw a number of sessions for which the final few messages were per RFC = 793: 12:48:41.728730 = www-14.nist.gov.http->stealth-10-32-244-222.cisco.com.65535 [.], 12:48:41.733051 = stealth-10-32-244-222.cisco.com.65535->www-14.nist.gov.http [.], 12:48:41.733447 = www-14.nist.gov.http->stealth-10-32-244-222.cisco.com.65535 [.], 12:48:41.733450 = www-14.nist.gov.http->stealth-10-32-244-222.cisco.com.65535 [FP.], 12:48:41.733471 = stealth-10-32-244-222.cisco.com.65535->www-14.nist.gov.http [.], 12:48:41.733480 = stealth-10-32-244-222.cisco.com.65535->www-14.nist.gov.http [.], 12:48:41.734286 = stealth-10-32-244-222.cisco.com.65535->www-14.nist.gov.http [F.], 12:48:41.872167 = www-14.nist.gov.http->stealth-10-32-244-222.cisco.com.65535 [.], I saw several that appeared to have closed the socket. When they = received a message, they replied with a RST. 12:48:56.044372 = stealth-10-32-244-222.cisco.com.49182->xfe-rcd3.cisco.com.https [P.], 12:48:56.126974 = xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49182 [P.], 12:48:56.127053 = stealth-10-32-244-222.cisco.com.49182->xfe-rcd3.cisco.com.https [.], 12:48:56.133520 = stealth-10-32-244-222.cisco.com.49182->xfe-rcd3.cisco.com.https [F.], 12:48:56.244610 = xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49182 [.], 12:48:56.244681 = stealth-10-32-244-222.cisco.com.49182->xfe-rcd3.cisco.com.https [.], 12:48:56.245276 = xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49182 [P.], 12:48:56.245330 = stealth-10-32-244-222.cisco.com.49182->xfe-rcd3.cisco.com.https [R], 12:48:56.245922 = xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49182 [F.], 12:48:56.245935 = stealth-10-32-244-222.cisco.com.49182->xfe-rcd3.cisco.com.https [R], I saw a whole lot that simply let the session lie. The following is an = entire https session. Where's the FIN or the RST? 12:48:59.432947 = stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [S], 12:48:59.517297 = xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [S.], 12:48:59.517352 = stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [.], 12:48:59.517752 = stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [P.], 12:48:59.605263 = xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [.], 12:48:59.608952 = xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [P.], 12:48:59.609010 = stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [.], 12:48:59.609664 = xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [P.], 12:48:59.609720 = stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [.], 12:48:59.610269 = xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [P.], 12:48:59.610342 = stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [.], 12:48:59.611640 = stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [P.], 12:48:59.611920 = stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [P.], 12:48:59.612054 = stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [P.], 12:48:59.699125 = xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [.], 12:48:59.705711 = xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [P.], 12:48:59.705783 = stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [.], 12:48:59.706462 = xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [P.], 12:48:59.706519 = stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [.], 12:48:59.706742 = stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [P.], 12:48:59.797729 = xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [P.], 12:48:59.797791 = stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [.], Yes, those are in fact the same two machines as the previous. If you're worried about Happy Eyeballs tripping up CGN, I submit that we = have a lot more to think about than Happy Eyeballs.= From moore@network-heretics.com Tue Feb 8 14:36:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2C743A6860 for ; Tue, 8 Feb 2011 14:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4jQ7YnOPcZ6 for ; Tue, 8 Feb 2011 14:36:48 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 8DD2C3A6857 for ; Tue, 8 Feb 2011 14:36:48 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmwB5-0003uo-AK; Tue, 08 Feb 2011 17:36:56 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110208212821.GA8815@srv03.cluenet.de> Date: Tue, 8 Feb 2011 17:36:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0B68F4F6-6D82-48FF-9843-556102575A88@network-heretics.com> References: <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> <54E900DC635DAB4DB7A6D799B3C4CD8E36726E@PDAWM12B.ad.sprint.com> <6DC6A648-5243-4259-BE2E-D25E17DF63C4@network-heretics.com> <20110208212821.GA8815@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940679f5e603fd64d9649176c399e9af15f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:36:51 -0000 On Feb 8, 2011, at 4:28 PM, Daniel Roesen wrote: > On Tue, Feb 08, 2011 at 04:12:36PM -0500, Keith Moore wrote: >> If an operator really needs to break 6to4, say because it is using = CGN, >> I agree that returning ICMP unreachable is probably the right thing = to do. >=20 > Wow, we finally agree on something. :-) >=20 >> But the filter should look deeper into the packet >=20 > Which is something that might have legal implications. Fine. Don't look deeper into the packet. Instead, route the packet to = a 6to4 "relay router" that forwards the traffic to a v6 "router" that = drops all packets, issues returns ICMPv6 responses for them, and routes = those ICMPv6 responses back through an opposite direction "relay router" = to the appropriate IPv4 source address. That will suffice. (Of course nothing says that both "relay routers" and the v6 "router" = can't all be in the same box.) >> than the protocol number so that it only filters 6to4-style tunneling >> and not configured tunnels. >=20 > The scenario which is our (residential ISPs forced to deploy some form > of LSN) focus would be packets sourced by customers egress towards = 6to4 > anycast relays. Those packets should be easily recognizable by = checking > for destination IP 192.88.99.1. Any packet destined to that IP should > trigger an ICMP unreachable message back to the sender, no matter what > protocol is used (we want to avoid "alive" checks going false = positive). I haven't tried it, but I suspect that doing an ICMPv6 response = encapsulated in a v4 packet, will work better than an ICMP response for = the original outer v4 packet. >> And breaking 6to4 should be considered a nuclear option. >=20 > It breaks anyway. We just look for ways to break it more gracefully, > read: don't have blackholing but give the 6to4 endpoint a chance to > notice that 6to4 won't work. >=20 >> It's far better to fix it. >=20 > Too late. IPv4 depletion is right here. Not that I like it as an > engineer, but we have to face operational realities. Sticking the head > into the sand, ignoring the problems ahead, is exactly what has put us > into this position in the first place. (I have to wonder if widespread adoption of CGN isn't yet another = product of "head in the sand" thinking.) Is your plan to deny EVERYBODY a properly working IPv4 address, or will = you make special cases for those whose apps break in the presence of = CGN? Keith From jbates@brightok.net Tue Feb 8 14:39:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4137E3A68BD for ; Tue, 8 Feb 2011 14:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.222 X-Spam-Level: X-Spam-Status: No, score=-3.222 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5y4tsjqJRDo for ; Tue, 8 Feb 2011 14:39:56 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 5BBCF3A6884 for ; Tue, 8 Feb 2011 14:39:56 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p18MdtXh026261; Tue, 8 Feb 2011 16:39:55 -0600 (CST) Message-ID: <4D51C63A.3040900@brightok.net> Date: Tue, 08 Feb 2011 16:39:54 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> <20110208215855.GC8815@srv03.cluenet.de> <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> In-Reply-To: <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:39:57 -0000 On 2/8/2011 4:31 PM, Fred Baker wrote: > If you're worried about Happy Eyeballs tripping up CGN, I submit that > we have a lot more to think about than Happy Eyeballs. I won't argue the point. There are a lot of things which don't play friendly with LSN, and even more things that LSN doesn't play friendly with. However, happy eyeballs can trip up an LSN when normal policy selection would have connections going via IPv6. The last resting piece of LSN is to handle v4 only connectivity while most traffic goes via IPv6. Happy Eyeballs can cripple this final picture if it isn't careful. Jack From jbates@brightok.net Tue Feb 8 14:45:29 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2343A68BD for ; Tue, 8 Feb 2011 14:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.222 X-Spam-Level: X-Spam-Status: No, score=-3.222 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCZjizPthrzb for ; Tue, 8 Feb 2011 14:45:28 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 3F3513A6857 for ; Tue, 8 Feb 2011 14:45:28 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18MjXUm003039; Tue, 8 Feb 2011 16:45:33 -0600 (CST) Message-ID: <4D51C78C.50508@brightok.net> Date: Tue, 08 Feb 2011 16:45:32 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> <54E900DC635DAB4DB7A6D799B3C4CD8E36726E@PDAWM12B.ad.sprint.com> <6DC6A648-5243-4259-BE2E-D25E17DF63C4@network-heretics.com> <20110208212821.GA8815@srv03.cluenet.de> <0B68F4F6-6D82-48FF-9843-556102575A88@network-heretics.com> In-Reply-To: <0B68F4F6-6D82-48FF-9843-556102575A88@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:45:29 -0000 Sorry for adding you back on Brian. :) On 2/8/2011 4:36 PM, Keith Moore wrote: > I haven't tried it, but I suspect that doing an ICMPv6 response > encapsulated in a v4 packet, will work better than an ICMP response > for the original outer v4 packet. Actually, it depends on the implementation. ICMP to the outer v4 packet can possibly disable 6to4 all together. ICMPv6 to the 6to4 node will stop that one connection. Ideally, you would do both, but that would be a custom implementation. I'm not completely sure it doesn't belong in Brian's draft as a suggestion (support for LSN systems to send both ICMP unreachable to v4 hosts using protocol 41 and ICMPv6 unreachable messages sent to the internal IPv6 hosts in protocol 41 packets). However, that is a vendor suggestion, not an operator one, and it's unclear which mechanism would be most effective in todays environment (since the dual method isn't implemented yet). Jack From dr@cluenet.de Tue Feb 8 14:46:47 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DBBD3A688E for ; Tue, 8 Feb 2011 14:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gwj50ZWObyg1 for ; Tue, 8 Feb 2011 14:46:46 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 4E5A53A6857 for ; Tue, 8 Feb 2011 14:46:46 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 60639108080; Tue, 8 Feb 2011 23:46:53 +0100 (CET) Date: Tue, 8 Feb 2011 23:46:53 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110208224653.GA13986@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> <20110208215855.GC8815@srv03.cluenet.de> <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:46:47 -0000 On Tue, Feb 08, 2011 at 02:31:13PM -0800, Fred Baker wrote: > I saw a whole lot that simply let the session lie. The following is an > entire https session. Where's the FIN or the RST? :-( I guess xfe-rcd3 is a HTTP proxy? Might it be a proxy-specific behaviour which wouldn't be relevant in the LSN scenario, as the LSN isn't between the endpoints and a HTTP proxy, but endpoints directly connecting to HTTP servers thru the LSN? Do you see the same effects when not using a web proxy? > If you're worried about Happy Eyeballs tripping up CGN, I submit that > we have a lot more to think about than Happy Eyeballs. We do. I was/am worried about making the problem even bigger by advocating detrimental behaviour (or more precisely: not advocating friendly behaviour). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From moore@network-heretics.com Tue Feb 8 14:50:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241543A67D3 for ; Tue, 8 Feb 2011 14:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfnguGnd5AQk for ; Tue, 8 Feb 2011 14:50:35 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 5D18E3A67A1 for ; Tue, 8 Feb 2011 14:50:35 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmwOP-0000dK-6U; Tue, 08 Feb 2011 17:50:42 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D51C78C.50508@brightok.net> Date: Tue, 8 Feb 2011 17:50:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <79D236D8-B514-460F-8322-7FD7774B9EEE@network-heretics.com> References: <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> <54E900DC635DAB4DB7A6D799B3C4CD8E36726E@PDAWM12B.ad.sprint.com> <6DC6A648-5243-4259-BE2E-D25E17DF63C4@network-heretics.com> <20110208212821.GA8815@srv03.cluenet.de> <0B68F4F6-6D82-48FF-9843-556102575A88@network-heretics.com> <4D51C78C.50508@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940575d2b7325073cec5f296686134a86b7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:50:36 -0000 On Feb 8, 2011, at 5:45 PM, Jack Bates wrote: > Sorry for adding you back on Brian. :) >=20 > On 2/8/2011 4:36 PM, Keith Moore wrote: >> I haven't tried it, but I suspect that doing an ICMPv6 response >> encapsulated in a v4 packet, will work better than an ICMP response >> for the original outer v4 packet. >=20 > Actually, it depends on the implementation. ICMP to the outer v4 = packet can possibly disable 6to4 all together. ICMPv6 to the 6to4 node = will stop that one connection. disabling all 6to4 is clearly broken. at most you want to disable 6to4 = that goes through your particular router. what I'm thinking is that ICMPv6 is more likely to get delivered to the = application and thus permit some sort of error message to get sent to = the user, logged, or whatever. Keith From jbates@brightok.net Tue Feb 8 14:54:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E50163A67D3 for ; Tue, 8 Feb 2011 14:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRK7mlc-8C8W for ; Tue, 8 Feb 2011 14:54:05 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 63E313A67A1 for ; Tue, 8 Feb 2011 14:54:05 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p18MsBjV004807; Tue, 8 Feb 2011 16:54:11 -0600 (CST) Message-ID: <4D51C992.1030501@brightok.net> Date: Tue, 08 Feb 2011 16:54:10 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> <54E900DC635DAB4DB7A6D799B3C4CD8E36726E@PDAWM12B.ad.sprint.com> <6DC6A648-5243-4259-BE2E-D25E17DF63C4@network-heretics.com> <20110208212821.GA8815@srv03.cluenet.de> <0B68F4F6-6D82-48FF-9843-556102575A88@network-heretics.com> <4D51C78C.50508@brightok.net> <79D236D8-B514-460F-8322-7FD7774B9EEE@network-heretics.com> In-Reply-To: <79D236D8-B514-460F-8322-7FD7774B9EEE@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:54:07 -0000 On 2/8/2011 4:50 PM, Keith Moore wrote: > disabling all 6to4 is clearly broken. at most you want to disable > 6to4 that goes through your particular router. > > what I'm thinking is that ICMPv6 is more likely to get delivered to > the application and thus permit some sort of error message to get > sent to the user, logged, or whatever. Yes, ICMPv6 is probably more likely to do that, though some 6to4 implementations will still do that (router to node behind it) and at the same time recognize that the 6to4 address isn't valid. If that happens to be the anycast address, it stops the cpe from continually trying to reach a 6to4 anycast. It's very implementation specific. Doing both at the same time would be cooler. Jack From moore@network-heretics.com Tue Feb 8 14:55:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0833A680C for ; Tue, 8 Feb 2011 14:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgMIODcxO0JV for ; Tue, 8 Feb 2011 14:55:48 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id E1F9A3A67A1 for ; Tue, 8 Feb 2011 14:55:47 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmwTP-0005St-Un; Tue, 08 Feb 2011 17:55:52 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D51C992.1030501@brightok.net> Date: Tue, 8 Feb 2011 17:55:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> <54E900DC635DAB4DB7A6D799B3C4CD8E36726E@PDAWM12B.ad.sprint.com> <6DC6A648-5243-4259-BE2E-D25E17DF63C4@network-heretics.com> <20110208212821.GA8815@srv03.cluenet.de> <0B68F4F6-6D82-48FF-9843-556102575A88@network-heretics.com> <4D51C78C.50508@brightok.net> <79D236D8-B514-460F-8322-7FD7774B9EEE@network-heretics.com> <4D51C992.1030501@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94024f9013f9baa89020454682993eab6e6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:55:50 -0000 On Feb 8, 2011, at 5:54 PM, Jack Bates wrote: > On 2/8/2011 4:50 PM, Keith Moore wrote: >> disabling all 6to4 is clearly broken. at most you want to disable >> 6to4 that goes through your particular router. >>=20 >> what I'm thinking is that ICMPv6 is more likely to get delivered to >> the application and thus permit some sort of error message to get >> sent to the user, logged, or whatever. >=20 > Yes, ICMPv6 is probably more likely to do that, though some 6to4 = implementations will still do that (router to node behind it) and at the = same time recognize that the 6to4 address isn't valid. If that happens = to be the anycast address, it stops the cpe from continually trying to = reach a 6to4 anycast. >=20 > It's very implementation specific. Doing both at the same time would = be cooler. strongly disagree, for a number of reasons. e.g. just because your = network is broken w.r.t. 6to4 doesn't mean that the host doesn't have = other connections available. From dr@cluenet.de Tue Feb 8 14:57:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C988E3A6857 for ; Tue, 8 Feb 2011 14:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4l+rERzvWUGQ for ; Tue, 8 Feb 2011 14:57:17 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id A48CC3A680C for ; Tue, 8 Feb 2011 14:56:58 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 2C07F108095; Tue, 8 Feb 2011 23:57:06 +0100 (CET) Date: Tue, 8 Feb 2011 23:57:06 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110208225706.GB13986@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <1297162751.4205.42.camel@shakira.millnert.se> <4D51B4E4.1070405@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:57:17 -0000 On Tue, Feb 08, 2011 at 05:27:29PM -0500, Keith Moore wrote: > > Although my own draft isn't directed at vendors, I have added > > this point. > > I think it's premature to stop enabling 6to4 by default. > > The appropriate date to start disabling 6to4 by default is > approximately the date at which operators' groups commit to lighting > up native v6 and providing it to their customers over the same > interfaces/links over which they currently provide v4. You will see exactly that happing within the next two years en masse, at least on the customer demarc (CPE LAN interface). Wether the WAN side will be native or tunnelled (6RD) will vary but from the user's perspective (and that's ~all that counts) it's dual-stack service being delivered. I took the industry actually facing IPv4 depletion to get moving. > If operators' groups would commit on behalf of their members to a > date for doing that, I would support publishing that date in an RFC and > recommending that implementations shipped after that date disable 6to4 > by default. Too late. You have a largish delay between "asking from something" and "getting it out of the door in mass". This is why we operators ask to advocate deprecating 6to4 _now_ so that it will hopefully have gained some traction when LSNs will get deployed at large - which I expect to happen in EU in the later 2011 and certainly in 2012. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From jbates@brightok.net Tue Feb 8 14:59:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADFD73A67D3 for ; Tue, 8 Feb 2011 14:59:12 -0800 (PST) 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.041, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKW1MSFL1-2S for ; Tue, 8 Feb 2011 14:59:10 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 865953A67A1 for ; Tue, 8 Feb 2011 14:59:10 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p18MxHih001338; Tue, 8 Feb 2011 16:59:17 -0600 (CST) Message-ID: <4D51CAC4.5070408@brightok.net> Date: Tue, 08 Feb 2011 16:59:16 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> <54E900DC635DAB4DB7A6D799B3C4CD8E36726E@PDAWM12B.ad.sprint.com> <6DC6A648-5243-4259-BE2E-D25E17DF63C4@network-heretics.com> <20110208212821.GA8815@srv03.cluenet.de> <0B68F4F6-6D82-48FF-9843-556102575A88@network-heretics.com> <4D51C78C.50508@brightok.net> <79D236D8-B514-460F-8322-7FD7774B9EEE@network-heretics.com> <4D51C992.1030501@brightok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:59:12 -0000 On 2/8/2011 4:55 PM, Keith Moore wrote: > On Feb 8, 2011, at 5:54 PM, Jack Bates wrote: > >> On 2/8/2011 4:50 PM, Keith Moore wrote: >>> disabling all 6to4 is clearly broken. at most you want to >>> disable 6to4 that goes through your particular router. >>> >>> what I'm thinking is that ICMPv6 is more likely to get delivered >>> to the application and thus permit some sort of error message to >>> get sent to the user, logged, or whatever. >> >> Yes, ICMPv6 is probably more likely to do that, though some 6to4 >> implementations will still do that (router to node behind it) and >> at the same time recognize that the 6to4 address isn't valid. If >> that happens to be the anycast address, it stops the cpe from >> continually trying to reach a 6to4 anycast. >> >> It's very implementation specific. Doing both at the same time >> would be cooler. > > strongly disagree, for a number of reasons. e.g. just because your > network is broken w.r.t. 6to4 doesn't mean that the host doesn't have > other connections available. > Ummm, if the host has other connections available, it shouldn't be sending to my anycast address. Also, sending an ICMPv6 to the application isn't going to use another host either. Your argument doesn't make sense. I didn't say it disables the gateway. I said it could keep it from constantly trying a futile act. I suspect that if it connects to another IPv4 address or is configured differently, it can send just fine to someone else's anycast. Jack From wwwrun@core3.amsl.com Tue Feb 8 15:01:43 2011 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A723F3A680C; Tue, 8 Feb 2011 15:01:43 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20110208230143.A723F3A680C@core3.amsl.com> Date: Tue, 8 Feb 2011 15:01:43 -0800 (PST) Cc: v6ops mailing list , Internet Architecture Board , v6ops chair , RFC Editor Subject: [v6ops] Resend: Document Action: 'Security Concerns With IP Tunneling' to Informational RFC (draft-ietf-v6ops-tunnel-security-concerns-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:01:43 -0000 The IESG has approved the following document: - 'Security Concerns With IP Tunneling' (draft-ietf-v6ops-tunnel-security-concerns-04.txt) as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-tunnel-security-concerns/ Technical Summary A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed today. Working Group Summary The document draft-ietf-v6ops-tunnel-security-concerns was accepted as working group document in july 2008. Last call following three revisions was completed 9/14. minor changes were made due to last call input and document was submitted to IESG on 10/27. Document Quality The document draft-ietf-v6ops-tunnel-security-concerns, addresses significant problems presented by ipv6 tunnels in an ipv4 and ipv6 security context. Since this document was conceived and initially socialized awareness of the problems and recommendations that the document contains has increased significantly. The document provides a problem statement and recommendations at a critical juncture and it's utility is straight-forward. Personnel Joel Jaeggli is the document shepherd. Ron Bonica is the responsible Area Director. RFC Editor Note * In the Abstract OLD: The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed today. NEW: The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. * After Section 5.1.1. OLD: NEW: 5.1.2. Discussion Several tunnel protocols use endpoint addresses that can be algorithmically derived from some known values. These addresses are structured and the fields contained in them can be fairly predictable. This reduces the search space for an attacker and reduces the resistance of the address to scanning attacks. e.g. Teredo addresses are formed using a well known prefix, client and server IPv4 addresses, the client port and a few flags. With a fairly narrow search space for most of these fields, it is easy to guess the tunnel endpoint address. 5.1.3. Recommendations It is recommended that the tunnel protocol developers use tunnel endpoint addresses that are not easily guessable. When the tunnel endpoint addresses are structured and fairly guessable, it is recommended that the implementation use any unused fields in the address to provide additional entropy to the address in order to reduce the address-scanning risks. e.g. This could be done by setting these unused fields to some random values. * In Section 6.1.3 OLD: The scope of the attack can also be reduced by limiting tunneling use in general but especially in preferring native IPv4 to tunneled IPv6; this is because it is reasonable to expect that banks and similar web sites will continue to be accessible over IPv4 for as long as a significant fraction of their customers are still IPv4-only. NEW: The scope of the attack can also be reduced by limiting tunneling use in general but especially in preferring native IPv4 to tunneled IPv6 while connecting to peers who are accessible over IPv4, as doing so precludes attacks that are facilitated by changing the tunnel server setting. From Wesley.E.George@sprint.com Tue Feb 8 15:06:35 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DDAC3A67D4 for ; Tue, 8 Feb 2011 15:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGnluSmn1tSb for ; Tue, 8 Feb 2011 15:06:33 -0800 (PST) Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by core3.amsl.com (Postfix) with ESMTP id 6C1F23A67A1 for ; Tue, 8 Feb 2011 15:06:33 -0800 (PST) Received: from mail167-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.8; Tue, 8 Feb 2011 23:06:41 +0000 Received: from mail167-tx2 (localhost.localdomain [127.0.0.1]) by mail167-tx2-R.bigfish.com (Postfix) with ESMTP id 2DFDA30749; Tue, 8 Feb 2011 23:06:41 +0000 (UTC) X-SpamScore: -35 X-BigFish: VS-35(zf7Iz542N9371Pzz1202hzz8275dh1033ILz2fh2a8h668h34h) X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI X-FB-SS: 0,0, Received: from mail167-tx2 (localhost.localdomain [127.0.0.1]) by mail167-tx2 (MessageSwitch) id 1297206400725431_5318; Tue, 8 Feb 2011 23:06:40 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.247]) by mail167-tx2.bigfish.com (Postfix) with ESMTP id AE5A1A00050; Tue, 8 Feb 2011 23:06:40 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 8 Feb 2011 23:06:40 +0000 Received: from PLSWEH01.ad.sprint.com (PLSWEH01.corp.sprint.com [144.226.242.129]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p18N6Exu005814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Feb 2011 17:06:38 -0600 Received: from PDAWM12B.ad.sprint.com ([fe80::64c8:fd69:1029:79b0]) by PLSWEH01.ad.sprint.com ([2002:90e2:f281::90e2:f281]) with mapi id 14.01.0270.001; Tue, 8 Feb 2011 17:06:34 -0600 From: "George, Wes E [NTK]" To: Keith Moore , Daniel Roesen Thread-Topic: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 Thread-Index: AQHLx9gaYJF3o3gjaUytpEh58zplsZP4J3+Q Date: Tue, 8 Feb 2011 23:06:33 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> In-Reply-To: <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.25] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0049_01CBC7BA.E9E737C0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:06:35 -0000 ------=_NextPart_000_0049_01CBC7BA.E9E737C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Keith Moore Sent: Tuesday, February 08, 2011 4:35 PM >I think the message needs to go out very clearly to users is this: >If your IPv6 access doesn't work, it's probably because your ISP (a) didn't plan ahead for v6 deployment and instead (b) imposed CGN >on you. You should find another ISP. [WEG] This is a really serious oversimplification of the situation, and IMO is harmful to the overall discussion, because it makes us look like we're more concerned with ideology than with practical and operational realities. Fact - Most users don't have enough IPv6 capable devices to move to using primarily IPv6 (let alone IPv6-only) anytime soon Fact - Most content isn't available on IPv6 (World IPv6 day will be interesting, but it doesn't solve the problem by a long shot) Fact - IPv4 is exhausted. Fact - Customers *will* find another ISP if their existing services quit working Defensible Theory - Customers are very likely to find a new ISP if their current one tells them that they have to replace all of the devices in their home/business that aren't IPv6-capable in order to keep their service working Example: Gaming box, Internet-capable A/V receiver or TV, etc. Corollary - CGN for IPv4 is virtually a requirement to make existing services keep working, assuming any growth at all. So, stop vilifying people who respond to that business reality. We're no happier about it than you are, and we *are* deploying IPv6, but we like to make sure our paychecks don't bounce. That said... ISPs *are* behind on IPv6 deployment. However, many ISPs don't control the end user's gear, and even if they were able to magically roll out network-wide support today, and assuming that the content problem is magically solved, a large majority of their customers wouldn't be able to take advantage of it either because of their CPE router or because the gear behind that router doesn't speak IPv6. There are many reasons that IPv6 isn't where we'd all like it to be, but pointing blame solely on the big, bad ISPs who are implementing CGN so that they don't have to do IPv6 is to miss a lot of the overall story. Wes George ------=_NextPart_000_0049_01CBC7BA.E9E737C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDITCCAx0CAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB8DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAyMDgyMzA2MzFaMCMGCSqGSIb3DQEJBDEWBBRVFcdovx7B RlG5KKEd5frnc4YZvTBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjCBlwYJKwYB BAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJp bnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNl IElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJEAILMYGJoIGGMHgx EzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/Is ZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRo b3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYAxkEb54QXV5Or8Zoo+NJIGj6qZB5Cf UAx3Puo2kG/nGasxbDC8l9J15v9pc3R2rPmwXCh6dEjHLiYdJn8QDGtTiwysgl6R/wjslaaFJMVT E/jJqMFD2vNxQ9HiOIvBxdFbzhVXwB1lIQ8GDFnGxf8+zHSxrca60GOdFowtKlTXcgAAAAAAAA== ------=_NextPart_000_0049_01CBC7BA.E9E737C0-- From dr@cluenet.de Tue Feb 8 15:14:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559A43A680C for ; Tue, 8 Feb 2011 15:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUxmHa-tc-ry for ; Tue, 8 Feb 2011 15:14:44 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 347033A67A1 for ; Tue, 8 Feb 2011 15:14:44 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id B79561080A2; Wed, 9 Feb 2011 00:14:51 +0100 (CET) Date: Wed, 9 Feb 2011 00:14:51 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110208231451.GC13986@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <20110207182427.GX44800@Space.Net> <4D504956.1050209@brightok.net> <1297146275.4205.14.camel@shakira.millnert.se> <4D50E44F.60609@bogus.com> <54E900DC635DAB4DB7A6D799B3C4CD8E36726E@PDAWM12B.ad.sprint.com> <6DC6A648-5243-4259-BE2E-D25E17DF63C4@network-heretics.com> <20110208212821.GA8815@srv03.cluenet.de> <0B68F4F6-6D82-48FF-9843-556102575A88@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0B68F4F6-6D82-48FF-9843-556102575A88@network-heretics.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:14:45 -0000 On Tue, Feb 08, 2011 at 05:36:49PM -0500, Keith Moore wrote: > Fine. Don't look deeper into the packet. Instead, route the packet > to a 6to4 "relay router" that forwards the traffic to a v6 "router" > that drops all packets, issues returns ICMPv6 responses for them, > and routes those ICMPv6 responses back through an opposite direction > "relay router" to the appropriate IPv4 source address. Not really possible in some LSN scenarios, as there is no router between the CPE and the LSN. E.g. DS-Lite. One would have to request that special handling of 6to4 packets from the LSN implementation. How feasibly that is depends on the implementation's architecture. > (Of course nothing says that both "relay routers" and the v6 "router" > can't all be in the same box.) Yup. > (I have to wonder if widespread adoption of CGN isn't yet another > product of "head in the sand" thinking.) Of course. Widespread adoption of LSN is a sign of failure of the whole Internet industry. Pretending it won't happen doesn't get us anywhere. We've already jumped out of the airplane. Time to find some emergency chutes to reduce impact velocity as far as possible. > Is your plan to deny EVERYBODY a properly working IPv4 address, or > will you make special cases for those whose apps break in the presence > of CGN? Do you really think that I'm entitled to disclose strategy details in the context of seriously disruptive changes in the residential ISP world? C'mon. :-) But as we all know, IPv6 is _the_ solution to any IPv4 breakage, so that will quickly become a non-issue anyway! :-P Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From jhw@apple.com Tue Feb 8 15:20:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDCC03A6841 for ; Tue, 8 Feb 2011 15:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikg+KrURubgG for ; Tue, 8 Feb 2011 15:20:38 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 297923A67A1 for ; Tue, 8 Feb 2011 15:20:38 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id 30A91D0D8AB1 for ; Tue, 8 Feb 2011 15:20:46 -0800 (PST) X-AuditID: 11807136-b7b89ae000000345-ac-4d51cfcee841 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay15.apple.com (Apple SCV relay) with SMTP id 09.DE.00837.ECFC15D4; Tue, 8 Feb 2011 15:20:46 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.14.84] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LGB00I15NIL2550@gertie.apple.com> for v6ops@ietf.org; Tue, 08 Feb 2011 15:20:46 -0800 (PST) From: james woodyatt Date: Tue, 08 Feb 2011 15:20:45 -0800 Message-id: <80570DB4-38CB-43B6-BC27-50F30E316499@apple.com> To: draft-korhonen-v6ops-3gpp-eps.authors@tools.ietf.org X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Operations Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:20:39 -0000 everyone-- I think I-D.korhonen-v6ops-3gpp-eps could be improved by referencing "Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC 4429]. In particular, I suggest making an explicit mention in section 5.2 by appending the following sentence to the second paragraph: > Link-local and global unicast addresses composed with this Interface Identifier are eligible for use with the optimistic DAD algorithm [RFC 4429]. An informative reference to RFC 4429 would be appropriate. -- james woodyatt member of technical staff, core os networking From dr@cluenet.de Tue Feb 8 15:23:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5903A67D4 for ; Tue, 8 Feb 2011 15:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_46=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fwoq65AYKMiA for ; Tue, 8 Feb 2011 15:23:20 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 7A06E3A67A1 for ; Tue, 8 Feb 2011 15:23:20 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 085DA1080A2; Wed, 9 Feb 2011 00:23:28 +0100 (CET) Date: Wed, 9 Feb 2011 00:23:28 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110208232327.GD13986@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:23:21 -0000 On Tue, Feb 08, 2011 at 11:06:33PM +0000, George, Wes E [NTK] wrote: > >I think the message needs to go out very clearly to users is this: > > >If your IPv6 access doesn't work, it's probably because your ISP (a) didn't plan ahead for v6 > deployment and instead (b) imposed CGN >on you. You should find another ISP. > > [WEG] This is a really serious oversimplification of the situation, and IMO is harmful to the > overall discussion, because it makes us look like we're more concerned with ideology than with > practical and operational realities. Indeed. And those kind of comments are exactly why "us operators" shy away from taking part in IETF WGs. Brian Carpenters FYI postings on ipv6-ops (an operator's mailing list) motivated me to invest time (my free time, not paid time) to contribute to frequently requested "operator's point of view". And frankly I have to admit that I considered to pull out of IETF discussions again today after seeing how this thread evolves, with so much outright denial of realities and subsequent time+energy wasted on that instead of focussing about how to properly deal with the realities (which is to - my understanding - v6ops' goal). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From fred@cisco.com Tue Feb 8 15:25:58 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93A23A68BD for ; Tue, 8 Feb 2011 15:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.868 X-Spam-Level: X-Spam-Status: No, score=-109.868 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2H0IDeh3HKB for ; Tue, 8 Feb 2011 15:25:58 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E61F13A67D4 for ; Tue, 8 Feb 2011 15:25:57 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAF9fUU2rR7H+/2dsb2JhbACfWIVqc6FXmzqFWgSEe4Zvgy4 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 08 Feb 2011 23:26:05 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p18NPM8I008935; Tue, 8 Feb 2011 23:26:05 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Tue, 08 Feb 2011 15:26:05 -0800 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Tue, 08 Feb 2011 15:26:05 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <20110208232327.GD13986@srv03.cluenet.de> Date: Tue, 8 Feb 2011 15:26:05 -0800 Message-Id: References: <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <20110208232327.GD13986@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:25:58 -0000 On Feb 8, 2011, at 3:23 PM, Daniel Roesen wrote: > And frankly I have to admit that I considered to pull out of IETF = discussions again today after seeing how this thread evolves, with so = much outright denial of realities and subsequent time+energy wasted on = that instead of focussing about how to properly deal with the realities = (which is to - my understanding - v6ops' goal). Please don't confuse "Keith Moore" with "The IETF".= From moore@network-heretics.com Tue Feb 8 15:34:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDBCB3A6836 for ; Tue, 8 Feb 2011 15:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMZ4mduGIHgx for ; Tue, 8 Feb 2011 15:34:08 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id C06593A68B0 for ; Tue, 8 Feb 2011 15:34:08 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Pmx4Z-0006wB-38; Tue, 08 Feb 2011 18:34:16 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> Date: Tue, 8 Feb 2011 18:34:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> To: "George, Wes E [NTK]" X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940f21559ccedf7d5a4efa89d0fa04f6759350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: "v6ops@ietf.org" , Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:34:10 -0000 On Feb 8, 2011, at 6:06 PM, George, Wes E [NTK] wrote: > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Keith Moore > Sent: Tuesday, February 08, 2011 4:35 PM >=20 >> I think the message needs to go out very clearly to users is this: >=20 >> If your IPv6 access doesn't work, it's probably because your ISP (a) = didn't plan ahead for v6 > deployment and instead (b) imposed CGN >on you. You should find = another ISP. >=20 > [WEG] This is a really serious oversimplification of the situation, = and IMO is harmful to the > overall discussion, because it makes us look like we're more concerned = with ideology than with > practical and operational realities.=20 I certainly get that impression from many of the participants here. = There's definitely an ideology that use of 6to4 is somehow not = legitimate and that it's therefore acceptable to sabotage it rather than = to try to fix it. (and I do realize that you can't really fix 6to4 over a link that is CGN = impaired, precisely because there is no explicit link setup for 6to4, = unlike say PPPoE.) > Fact - Most users don't have enough IPv6 capable devices to move to = using primarily IPv6 (let alone > IPv6-only) anytime soon Really? All of the major OS vendors have been shipping IPv6 support = for several years now. Sure, there are still a few people running Win = 2k, me, 98, or even 95, but not many. > Fact - Most content isn't available on IPv6 (World IPv6 day will be = interesting, but it doesn't > solve the problem by a long shot) The idea that the internet's only purpose is for users to get "content" = has always struck me as bizarre. =20 > Fact - IPv4 is exhausted. > Fact - Customers *will* find another ISP if their existing services = quit working > Defensible Theory - Customers are very likely to find a new ISP if = their current one tells them that > they have to replace all of the devices in their home/business that = aren't IPv6-capable in order to > keep their service working yeah, that much sounds right. > Example: Gaming box, Internet-capable A/V receiver or TV, etc. > Corollary - CGN for IPv4 is virtually a requirement to make existing = services keep working, assuming > any growth at all. CGN is also going to make existing services break, likely causing users = to switch ISPs. > So, stop vilifying people who respond to that business reality. We're = no happier about it than you > are, and we *are* deploying IPv6, but we like to make sure our = paychecks don't bounce. The damage has already been done by not ramping up MUCH sooner on native = v6. Many ISPs are now in a position that they cannot help but break = things for their customers in a number of different ways, regardless of = whether the customer is using 6to4 or not. If customers interpret that = breakage as a sign that their ISP isn't doing its job, and switches ISPs = until things start working well again, they won't be far wrong.=20 If ISPs are paranoid about this, well, I guess I'm not surprised. My purpose here is not to bash network operators. Nor do I really want = to encourage users to riot. =20 But when operators start blaming 6to4 on problems that were actually = caused by operators, it's hard to see how they can find suitable = solutions. Keith From moore@network-heretics.com Tue Feb 8 15:45:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB3B03A68B1 for ; Tue, 8 Feb 2011 15:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUUMDugxxxPe for ; Tue, 8 Feb 2011 15:45:54 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 8FE323A6894 for ; Tue, 8 Feb 2011 15:45:54 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmxFx-0008NW-9H; Tue, 08 Feb 2011 18:46:02 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110208225706.GB13986@srv03.cluenet.de> Date: Tue, 8 Feb 2011 18:45:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <1297162751.4205.42.camel@shakira.millnert.se> <4D51B4E4.1070405@gmail.com> <20110208225706.GB13986@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94091ff8bee88b11dfec20aaa09705c3105350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:45:55 -0000 On Feb 8, 2011, at 5:57 PM, Daniel Roesen wrote: > On Tue, Feb 08, 2011 at 05:27:29PM -0500, Keith Moore wrote: >>> Although my own draft isn't directed at vendors, I have added >>> this point. >>=20 >> I think it's premature to stop enabling 6to4 by default. =20 >>=20 >> The appropriate date to start disabling 6to4 by default is >> approximately the date at which operators' groups commit to lighting >> up native v6 and providing it to their customers over the same >> interfaces/links over which they currently provide v4. >=20 > You will see exactly that happing within the next two years en masse, > at least on the customer demarc (CPE LAN interface). Wether the WAN = side > will be native or tunnelled (6RD) will vary but from the user's > perspective (and that's ~all that counts) it's dual-stack service > being delivered. >=20 > I took the industry actually facing IPv4 depletion to get moving. I'm happy to hear that, though I'll be happier if the industry can put a = stake in the ground and commit to a date. >> If operators' groups would commit on behalf of their members to a >> date for doing that, I would support publishing that date in an RFC = and >> recommending that implementations shipped after that date disable = 6to4 >> by default. >=20 > Too late. You have a largish delay between "asking from something" and > "getting it out of the door in mass". This is why we operators ask to > advocate deprecating 6to4 _now_ so that it will hopefully have gained > some traction when LSNs will get deployed at large - which I expect to > happen in EU in the later 2011 and certainly in 2012. Well, sure. We ask _now_ for 6to4 to be disabled by default starting = _at a particular date_. That way, vendors get plenty of lead time. =20 But part of the message needs to be that the industry commits to = delivering native v6 by that date. That informs users of the timeframe = and migration path. It also tells content providers when they can stop = trying to work around 6to4-related issues. =20 Keith= From jhw@apple.com Tue Feb 8 15:52:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFCD53A682C for ; Tue, 8 Feb 2011 15:52:56 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkgNvkVkuqJA for ; Tue, 8 Feb 2011 15:52:56 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 080AF3A67ED for ; Tue, 8 Feb 2011 15:52:56 -0800 (PST) Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out3.apple.com (Postfix) with ESMTP id 222CCCD8F4D7 for ; Tue, 8 Feb 2011 15:53:04 -0800 (PST) X-AuditID: 11807135-b7cf8ae0000007ed-56-4d51d75f7fe8 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay12.apple.com (Apple SCV relay) with SMTP id 3A.4B.02029.F57D15D4; Tue, 8 Feb 2011 15:53:04 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.14.84] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LGB00CTBP0F0R10@elliott.apple.com> for v6ops@ietf.org; Tue, 08 Feb 2011 15:53:03 -0800 (PST) From: james woodyatt In-reply-to: <20110208225706.GB13986@srv03.cluenet.de> Date: Tue, 08 Feb 2011 15:53:03 -0800 Message-id: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <1297162751.4205.42.camel@shakira.millnert.se> <4D51B4E4.1070405@gmail.com> <20110208225706.GB13986@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:52:56 -0000 On Feb 8, 2011, at 14:57, Daniel Roesen wrote: > This is why we operators ask to advocate deprecating 6to4 _now_ so that it will hopefully have gained some traction when LSNs will get deployed at large - which I expect to happen in EU in the later 2011 and certainly in 2012. Speaking as an individual with experience in the residential gateway equipment maker community, let me address the operational community as a whole on this topic... p1. Moving RFC 3056 to Historic status won't fix any broken 6to4 anycast relays. p2. Moving RFC 3056 to Historic status won't force residential gateway equipment makers to do any of the following in their future products: + Remove the 6to4 tunneled routing feature. + Make the 6to4 tunneled routing feature an opt-in configuration. + Make the 6to4 tunneled routing feature continually probe the anycast relay to make sure it's functioning properly before forwarding packets to it. (Many relays silently drop such probes while otherwise functioning properly.) + Make the 6to4 tunneled routing feature respond to receipt of an ICMPv6 error packet by shutting down all forwarding to the 6to4 relay. (Sounds like a denial of service attack opportunity to me.) + Update the firmware in already deployed products in the field to do any of the above. p3. Moving RFC 3056 to Historic status won't force residential gateway equipment makers to stop selling gear that can tunnel 6to4 to anycast relay routers. I appreciate that residential gateways with 6to4 tunneled routing features pose transition problems for service providers and other members of the operational community, but my advice is to stop considering them to be a "problem" and start treating them like a Terrain Feature. They're not going away. Equipment makers aren't even going to stop selling new ones. A significant fraction of customers are like Mr. Keith Moore here on the V6OPS list, and they like the 6to4 routing feature, because it lets them get better-than-nothing IPv6 service in the face of incumbent oligopolist service providers that can't or won't offer them native IPv6 service. Any hope you might have that turning RFC 3056 to Historic status will change the basic terrain in which you're operating is badly misplaced. -- james woodyatt member of technical staff, core os networking From dr@cluenet.de Tue Feb 8 15:56:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4365E3A682C for ; Tue, 8 Feb 2011 15:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufY-mBVLVOFW for ; Tue, 8 Feb 2011 15:56:09 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id F1EEC3A67ED for ; Tue, 8 Feb 2011 15:56:08 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id A3FB71080A7; Wed, 9 Feb 2011 00:56:15 +0100 (CET) Date: Wed, 9 Feb 2011 00:56:15 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110208235615.GB17091@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:56:10 -0000 On Tue, Feb 08, 2011 at 06:34:11PM -0500, Keith Moore wrote: > CGN is also going to make existing services break, likely causing > users to switch ISPs. Those will have a hard time finding an alternate ISP _not_ using LSN in the near future. Differentiation will not be "is or is not doing LSN", but the exact way of doing LSN and making it as painless as possible. Finding a workaround to the 6to4 problems arising of LSNs (in addition to the "natural" problems of anycast 6to4) is part of that equation. And part of why I'm here in the first place. To work on aggregated "wisdom" on how to tackle the dirty details which we can then take as internal and external (to vendors) reference. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From jhw@apple.com Tue Feb 8 15:58:47 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00B93A6837 for ; Tue, 8 Feb 2011 15:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrUdShoXK0QX for ; Tue, 8 Feb 2011 15:58:47 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 0D0A33A67ED for ; Tue, 8 Feb 2011 15:58:47 -0800 (PST) Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out3.apple.com (Postfix) with ESMTP id 5A400CD8F919 for ; Tue, 8 Feb 2011 15:58:55 -0800 (PST) X-AuditID: 11807135-b7cf8ae0000007ed-37-4d51d8bfb798 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay12.apple.com (Apple SCV relay) with SMTP id ED.9C.02029.FB8D15D4; Tue, 8 Feb 2011 15:58:55 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.14.84] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LGB00CXPPA60R10@elliott.apple.com> for v6ops@ietf.org; Tue, 08 Feb 2011 15:58:55 -0800 (PST) From: james woodyatt In-reply-to: Date: Tue, 08 Feb 2011 15:58:54 -0800 Message-id: References: To: Basavaraj.Patil@nokia.com X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: draft-korhonen-v6ops-3gpp-eps.authors@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:58:47 -0000 On Feb 8, 2011, at 15:26, Basavaraj.Patil@nokia.com wrote: > This I-D is explaining the operation of address assignment, PDP > context/PDN connection setup procedures as defined in 3GPP. Referencing > Optimistic DAD in the context of this paragraph without there being > equivalent text in 3GPP would cause them to be misaligned. Okay. Does that mean that the IID signaled in the PDN connection setup is *NOT eligible for use with the RFC 4429 optimistic DAD algorithm? Why wouldn't it be? If that's the case, then surely the draft should be amended to explain that! -- james woodyatt member of technical staff, core os networking From moore@network-heretics.com Tue Feb 8 16:06:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4FE43A6837 for ; Tue, 8 Feb 2011 16:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlQ4-mUxslIh for ; Tue, 8 Feb 2011 16:06:33 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 9C69C3A68B1 for ; Tue, 8 Feb 2011 16:06:29 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmxZp-0005Fr-Lk; Tue, 08 Feb 2011 19:06:34 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110208232327.GD13986@srv03.cluenet.de> Date: Tue, 8 Feb 2011 19:06:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <40E108BC-6709-4596-844B-B7E59F2643C7@network-heretics.com> References: <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <20110208232327.GD13986@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940185fe5552419277c977446529bf1b793350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 00:06:34 -0000 On Feb 8, 2011, at 6:23 PM, Daniel Roesen wrote: > On Tue, Feb 08, 2011 at 11:06:33PM +0000, George, Wes E [NTK] wrote: >>> I think the message needs to go out very clearly to users is this: >>=20 >>> If your IPv6 access doesn't work, it's probably because your ISP (a) = didn't plan ahead for v6 >> deployment and instead (b) imposed CGN >on you. You should find = another ISP. >>=20 >> [WEG] This is a really serious oversimplification of the situation, = and IMO is harmful to the >> overall discussion, because it makes us look like we're more = concerned with ideology than with >> practical and operational realities.=20 >=20 > Indeed. And those kind of comments are exactly why "us operators" shy > away from taking part in IETF WGs. Look, I didn't jump into this discussion with the purpose of pointing = fingers at operators. =20 But when people here start blaming 6to4 for problems that are caused by = various kinds of brain-damage inside the network, and trying to kill = 6to4 for that reason and before there's a suitable replacement, I think = it's fair to point out that the actual culpability lies elsewhere. Not = because I want to have a big argument about it, but because I don't see = how any problem can be solved by people who insist on blaming the = symptom. Meanwhile, I've also been trying to contribute to discussions about how = to (a) gracefully phase out 6to4 in favor of native v6, and (b) allow = 6to4 to continue working until that happens. I think it's much more = appropriate to devote attention to those topics than to "who is to = blame". But it's hard to do that while people are still trying to kill = 6to4 prematurely. > And frankly I have to admit that I considered to pull out of IETF > discussions again today after seeing how this thread evolves, with > so much outright denial of realities and subsequent time+energy > wasted on that instead of focussing about how to properly deal with = the > realities (which is to - my understanding - v6ops' goal). Properly dealing with the realities is my concern also. (and I'm not = getting paid for my contribution to this discussion, either). Keith From moore@network-heretics.com Tue Feb 8 16:06:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B4E23A68DE for ; Tue, 8 Feb 2011 16:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKPZIxUSEqRe for ; Tue, 8 Feb 2011 16:06:58 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 168143A68B1 for ; Tue, 8 Feb 2011 16:06:58 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PmxaL-0005Fr-6O; Tue, 08 Feb 2011 19:07:05 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Tue, 8 Feb 2011 19:07:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <22CF9F12-B4D6-4E14-BB1C-22C2B9D9D3EB@network-heretics.com> References: <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <20110208232327.GD13986@srv03.cluenet.de> To: Fred Baker X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940f1cf823292422a9a650859b1316fb65f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 00:06:59 -0000 Fred, I'll ask that you please refrain from ad hominem attacks. On Feb 8, 2011, at 6:26 PM, Fred Baker wrote: >=20 > On Feb 8, 2011, at 3:23 PM, Daniel Roesen wrote: >=20 >> And frankly I have to admit that I considered to pull out of IETF = discussions again today after seeing how this thread evolves, with so = much outright denial of realities and subsequent time+energy wasted on = that instead of focussing about how to properly deal with the realities = (which is to - my understanding - v6ops' goal). >=20 > Please don't confuse "Keith Moore" with "The IETF". > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From townsley@cisco.com Tue Feb 8 16:08:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 820AA3A68D1 for ; Tue, 8 Feb 2011 16:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDK9i+cmOA78 for ; Tue, 8 Feb 2011 16:08:07 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0DD073A6837 for ; Tue, 8 Feb 2011 16:08:06 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngEAHRpUU2Q/khLgWdsb2JhbACfWIVqFQEBFiIkoW2bOYVaBItqgy8 Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 09 Feb 2011 00:08:14 +0000 Received: from [10.104.75.230] (dhcp-10-55-88-106.cisco.com [10.55.88.106]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p1908EVc031976; Wed, 9 Feb 2011 00:08:14 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Wed, 9 Feb 2011 01:08:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <10103E3F-E094-451C-BE8A-61EAE2D4D4F8@cisco.com> References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <1297162751.4205.42.camel@shakira.millnert.se> <4D51B4E4.1070405@gmail.com> <20110208225706.GB13986@srv03.cluenet.de> To: james woodyatt X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 00:08:09 -0000 Sometimes we, or others, publish documents that cause action to occur. = Other times the documents are simply ignored. Predicting which is which = at time of publication is often difficult.=20 I know of at least a few manufacturers who incorporated 6to4 into their = products due to a very specific "logo" requirement that recommended it. = It wasn't directly due to an IETF document in this case, but certainly = the requirement pointed to an IETF document. It's not precisely the same thing, but I've seen on numerous product = documents, presentations, etc. that "NAT-PT" was bad because the "IETF = deprecated it", even if the IETF turned around and chartered work to = solve the same problem in Behave just after (even if the vast majority = of the reasons identified in the deprecation of NAT-PT are also = applicable to the Behave work) . Sometimes you just don't know what the = world is going to latch onto.=20 I think it's time to move on from 6to4. Sure, moving it to Historic = won't necessarily have an affect, but it might. At least the logo = programs out there that point to 6to4 might be triggered to update a = pointer and in the process consider whether or not to remove the = requirement altogether.=20 - Mark On Feb 9, 2011, at 12:53 AM, james woody=20 att wrote: > On Feb 8, 2011, at 14:57, Daniel Roesen wrote: >=20 >> This is why we operators ask to advocate deprecating 6to4 _now_ so = that it will hopefully have gained some traction when LSNs will get = deployed at large - which I expect to happen in EU in the later 2011 and = certainly in 2012. >=20 > Speaking as an individual with experience in the residential gateway = equipment maker community, let me address the operational community as a = whole on this topic... >=20 > p1. Moving RFC 3056 to Historic status won't fix any broken 6to4 = anycast relays. >=20 > p2. Moving RFC 3056 to Historic status won't force residential gateway = equipment makers to do any of the following in their future products: >=20 > + Remove the 6to4 tunneled routing feature. >=20 > + Make the 6to4 tunneled routing feature an opt-in configuration. >=20 > + Make the 6to4 tunneled routing feature continually probe the = anycast relay to make sure it's functioning properly before forwarding = packets to it. (Many relays silently drop such probes while otherwise = functioning properly.) >=20 > + Make the 6to4 tunneled routing feature respond to receipt of an = ICMPv6 error packet by shutting down all forwarding to the 6to4 relay. = (Sounds like a denial of service attack opportunity to me.) >=20 > + Update the firmware in already deployed products in the field to do = any of the above. >=20 > p3. Moving RFC 3056 to Historic status won't force residential gateway = equipment makers to stop selling gear that can tunnel 6to4 to anycast = relay routers. >=20 > I appreciate that residential gateways with 6to4 tunneled routing = features pose transition problems for service providers and other = members of the operational community, but my advice is to stop = considering them to be a "problem" and start treating them like a = Terrain Feature. >=20 > They're not going away. Equipment makers aren't even going to stop = selling new ones. >=20 > A significant fraction of customers are like Mr. Keith Moore here on = the V6OPS list, and they like the 6to4 routing feature, because it lets = them get better-than-nothing IPv6 service in the face of incumbent = oligopolist service providers that can't or won't offer them native IPv6 = service. >=20 > Any hope you might have that turning RFC 3056 to Historic status will = change the basic terrain in which you're operating is badly misplaced. >=20 >=20 > -- > james woodyatt > member of technical staff, core os networking >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Tue Feb 8 16:42:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231A53A6857 for ; Tue, 8 Feb 2011 16:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuauHYs-pdqi for ; Tue, 8 Feb 2011 16:42:18 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 6AF723A6836 for ; Tue, 8 Feb 2011 16:42:18 -0800 (PST) Received: by pwi7 with SMTP id 7so7447pwi.31 for ; Tue, 08 Feb 2011 16:42:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AHpWaC3nNG9u+6UJPubeppbLu8W5SroWbAsaERBrPZY=; b=TqamdvknkSNA9oYhYn5JZR0NyrsJYI2nAjYbRAmpzXnS8lPVEwkWKEx3On2OvZnrVD gd4rHkUkC03htGt0QRmRLudpWofo8uQPkmcqXKmFfgULYLEmrwRh8dy7GEDp5lwqM7Vv 4Wlw830PpPD30w+wSVfOm/UaTfBLBSuHEvl5U= 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=LjBhPQWTleB80+I11bp7kR/FCGrEvhyDBwPjD8D5XoE64DZ7tG1n3UMA7kg7xJ602t uO2EO3aN6kOojnNsm2dIf0tC/xlYupzbB0Ad1MzO5UAkblvg+P7w+EgyJdPnjyb+bbQB eS3hdata1wfBOlZS1EqdJGSO7Mn0YT8CGiEGE= Received: by 10.142.188.18 with SMTP id l18mr17811638wff.52.1297212146471; Tue, 08 Feb 2011 16:42:26 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id b11sm263218wff.9.2011.02.08.16.42.23 (version=SSLv3 cipher=OTHER); Tue, 08 Feb 2011 16:42:25 -0800 (PST) Message-ID: <4D51E2FA.8020903@gmail.com> Date: Wed, 09 Feb 2011 13:42:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Townsley References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <1297162751.4205.42.camel@shakira.millnert.se> <4D51B4E4.1070405@gmail.com> <20110208225706.GB13986@srv03.cluenet.de> <10103E3F-E094-451C-BE8A-61EAE2D4D4F8@cisco.com> In-Reply-To: <10103E3F-E094-451C-BE8A-61EAE2D4D4F8@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen Subject: [v6ops] Logos? [New Version Notification for draft-troan-v6ops-6to4-to-historic-00] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 00:42:19 -0000 Mark, > I think it's time to move on from 6to4. Sure, moving it to Historic won't necessarily have an affect, but it might. At least the logo programs out there that point to 6to4 might be triggered to update a pointer and in the process consider whether or not to remove the requirement altogether. Are you saying that there are *requirements* lists including RFC 3068? I just checked the old and new IETF node requirements and neither of them mention it (nor RFC 3056). I don't have current NIST or DoD profiles to hand, but I can find no trace of 6to4 in the old versions that I do have (and the DoD says that Teredo "is strongly discouraged, and will be prohibited in some DoD networks"). So which profiles require 6to4? Brian From jhw@apple.com Tue Feb 8 18:43:07 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04D83A681A for ; Tue, 8 Feb 2011 18:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pM1Z+AEj-6e for ; Tue, 8 Feb 2011 18:43:07 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id F351C3A6806 for ; Tue, 8 Feb 2011 18:43:06 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 0EDEBD0E45BF for ; Tue, 8 Feb 2011 18:43:15 -0800 (PST) X-AuditID: 1180711d-b7c12ae00000228a-6d-4d51ff428f39 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay13.apple.com (Apple SCV relay) with SMTP id 92.77.08842.24FF15D4; Tue, 8 Feb 2011 18:43:15 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from 67-218-106-172.cust.layer42.net (67-218-106-172.cust.layer42.net [67.218.106.172]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LGB00123WVZQ800@et.apple.com> for v6ops@ietf.org; Tue, 08 Feb 2011 18:43:14 -0800 (PST) From: james woodyatt In-reply-to: Date: Tue, 08 Feb 2011 18:43:11 -0800 Message-id: <59980476-D8F4-4AA0-976F-9DCECB5550DB@apple.com> References: To: draft-korhonen-v6ops-3gpp-eps.authors@tools.ietf.org X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Operations Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 02:43:07 -0000 On Feb 8, 2011, at 15:58, james woodyatt wrote: > > Okay. Does that mean that the IID signaled in the PDN connection setup is *NOT eligible for use with the RFC 4429 optimistic DAD algorithm? Why wouldn't it be? If that's the case, then surely the draft should be amended to explain that! Ah. I see my goof. The draft says this: > The details of the 3GPP link-model and address configuration is described in Section 11.2.1.3.2a of [3GPP.29.061]. That document elaborates: > Since the GGSN guarantees that the Prefix is unique, the MS does not need to perform any Duplicate Address Detection on addresses it creates. That is, the 'DupAddrDetectTransmits' variable in the MS should have a value of zero. If the MS finds more than one Prefix in the Router Advertisement message, it shall only consider the first one and silently discard the others. The GGSN shall not generate any globally unique IPv6 addresses for itself using the Prefix assigned to the MS in the Router Advertisement. It seems to me like this draft would be improved by spelling that out explicitly here too. On a related note, I didn't find any specific language in the 3GPP draft explaining what to do when the PIO option in the RA message contains a prefix length shorter than 64 bits. Seems like an oversight. One assumes that zero-extending to 64 bits is acceptable, but a normative instruction would be better. -- james woodyatt member of technical staff, core os networking From joelja@bogus.com Tue Feb 8 19:34:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFEFB3A68E3 for ; Tue, 8 Feb 2011 19:34:06 -0800 (PST) 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_13=0.6, J_CHICKENPOX_46=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQ320U-q932Z for ; Tue, 8 Feb 2011 19:34:05 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 557403A682E for ; Tue, 8 Feb 2011 19:34:05 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p193YAnX017562 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Wed, 9 Feb 2011 03:34:10 GMT (envelope-from joelja@bogus.com) Message-ID: <4D520B31.8000406@bogus.com> Date: Tue, 08 Feb 2011 19:34:09 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: v6ops@ietf.org References: <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <20110208232327.GD13986@srv03.cluenet.de> In-Reply-To: <20110208232327.GD13986@srv03.cluenet.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 03:34:06 -0000 On 2/8/11 3:23 PM, Daniel Roesen wrote: > Indeed. And those kind of comments are exactly why "us operators" shy > away from taking part in IETF WGs. Brian Carpenters FYI postings on > ipv6-ops (an operator's mailing list) motivated me to invest time (my > free time, not paid time) to contribute to frequently requested > "operator's point of view". Two of three working group chairs are network operators, the third is I think fairly sensitive to the needs of his customers. Inclusive of the participants, v6ops actually has fairly rich operational representation, which is worth remembering. Not all operators speak with one voice however. The important part is not to foster an us vs them mentality Whomever them is, there is only us. > And frankly I have to admit that I considered to pull out of IETF > discussions again today after seeing how this thread evolves, with > so much outright denial of realities and subsequent time+energy > wasted on that instead of focussing about how to properly deal with the > realities (which is to - my understanding - v6ops' goal). The reality is that disputes occur, cooling off some points of contention is required before they can be touched again, and ultimately as individual contributors we have to do what's right in our opinion or for our organizations. We're more effective if we produce consensus, but not all outcomes produce or require that. > Best regards, > Daniel > joel From Basavaraj.Patil@nokia.com Tue Feb 8 15:27:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055343A688C for ; Tue, 8 Feb 2011 15:27:03 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0X1uMZ6A3GO for ; Tue, 8 Feb 2011 15:27:02 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 1FCC03A6841 for ; Tue, 8 Feb 2011 15:27:02 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p18NR7ge021250; Wed, 9 Feb 2011 01:27:07 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 01:26:59 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 9 Feb 2011 00:26:58 +0100 Received: from 008-AM1MPN1-005.mgdnok.nokia.com ([169.254.4.149]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi; Wed, 9 Feb 2011 00:26:59 +0100 From: To: , Thread-Topic: draft-korhonen-v6ops-3gpp-eps Thread-Index: AQHLx+bgk1FA7ccka0K5lubielmVUZP3yheA Date: Tue, 8 Feb 2011 23:26:33 +0000 Message-ID: In-Reply-To: <80570DB4-38CB-43B6-BC27-50F30E316499@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 Content-Type: text/plain; charset="us-ascii" Content-ID: <434fd2dc-e33c-4e08-bd31-05a35a5bf703> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2011 23:26:59.0209 (UTC) FILETIME=[AEAC4790:01CBC7E7] X-Nokia-AV: Clean X-Mailman-Approved-At: Tue, 08 Feb 2011 19:41:05 -0800 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:27:03 -0000 This I-D is explaining the operation of address assignment, PDP context/PDN connection setup procedures as defined in 3GPP. Referencing Optimistic DAD in the context of this paragraph without there being equivalent text in 3GPP would cause them to be misaligned. -Raj On 2/8/11 5:20 PM, "ext james woodyatt" wrote: >everyone-- > >I think I-D.korhonen-v6ops-3gpp-eps could be improved by referencing >"Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC 4429]. In >particular, I suggest making an explicit mention in section 5.2 by >appending the following sentence to the second paragraph: > >> Link-local and global unicast addresses composed with this Interface >>Identifier are eligible for use with the optimistic DAD algorithm [RFC >>4429]. > >An informative reference to RFC 4429 would be appropriate. > > >-- >james woodyatt >member of technical staff, core os networking > > > From rogerj@gmail.com Tue Feb 8 22:36:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5CF3A687F for ; Tue, 8 Feb 2011 22:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yu-RMkfmdOXv for ; Tue, 8 Feb 2011 22:36:53 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 57B4D3A685D for ; Tue, 8 Feb 2011 22:36:53 -0800 (PST) Received: by vws7 with SMTP id 7so3592051vws.31 for ; Tue, 08 Feb 2011 22:37:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=I4bPHgVPxNmw/LZDesq7pHEienwDnQkVfY5OW/xm2zo=; b=Z+gJxBgf6zjRWKtJofrFgrrLntIYXpB2tUnBDJ8x0Rxxd9hjlYHCs1FkAAWTL2DAk4 V9GRt94ux5ZZclzVKuGKY1B3qfclJ4XID/TW6b+eD5XdWVFmJffgtiSafNejNwbxlZo0 VT5mmKGB8Iaw4u6yxImWXiPYWhi7biupTahrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=gT3No2VLONHDaXe7TFAhhBltwlOmyRB6dlQzXS+JnNWjeQZlKFiyTxQxyTWAzOW3uo IGKPcRBrE6YrK5L183nf903S/6gkHfGSR44IdJQX00cBM+YkleqQk3QVB0EP0EqA5BQV wKrWsqDpc6Mv3iUmsPpNmzv7Yp7jgmW0gS7nA= MIME-Version: 1.0 Received: by 10.220.175.130 with SMTP id ba2mr5081786vcb.24.1297233421759; Tue, 08 Feb 2011 22:37:01 -0800 (PST) Received: by 10.220.203.137 with HTTP; Tue, 8 Feb 2011 22:37:01 -0800 (PST) In-Reply-To: <20110208224653.GA13986@srv03.cluenet.de> References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> <20110208215855.GC8815@srv03.cluenet.de> <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> <20110208224653.GA13986@srv03.cluenet.de> Date: Wed, 9 Feb 2011 07:37:01 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 06:36:56 -0000 On Tue, Feb 8, 2011 at 11:46 PM, Daniel Roesen wrote: > On Tue, Feb 08, 2011 at 02:31:13PM -0800, Fred Baker wrote: >> If you're worried about Happy Eyeballs tripping up CGN, I submit that >> we have a lot more to think about than Happy Eyeballs. > > We do. I was/am worried about making the problem even bigger by > advocating detrimental behaviour (or more precisely: not advocating > friendly behaviour). I think you might overlook another _maybe_ more important point to consider. This might not be technical but more timedepending. Will Happy Eyeballs get out in time or not? I see people trying to get things perfect, that's great but takes time, are we sure there is enough time to get things perfect? Would a 90% solution work NOW? And in ~6-12months time get a version 2 out that is 98%? --=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 fred@cisco.com Tue Feb 8 22:42:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7633F3A6900 for ; Tue, 8 Feb 2011 22:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.074 X-Spam-Level: X-Spam-Status: No, score=-110.074 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-Q19h8TtnrI for ; Tue, 8 Feb 2011 22:42:34 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2FE8A3A68BD for ; Tue, 8 Feb 2011 22:42:34 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALvGUU2rRN+K/2dsb2JhbAClRHOiD5skhVsEhH2GcYMxgwg Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 09 Feb 2011 06:42:43 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p196gcpA019105; Wed, 9 Feb 2011 06:42:43 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Tue, 08 Feb 2011 22:42:43 -0800 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Tue, 08 Feb 2011 22:42:43 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Tue, 8 Feb 2011 22:42:28 -0800 Message-Id: <6EC9053B-AAFC-4C50-9C8D-46C2710CE092@cisco.com> References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> <20110208215855.GC8815@srv03.cluenet.de> <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> <20110208224653.GA13986@srv03.cluenet.de> To: =?iso-8859-1?Q?Roger_J=F8rgensen?= X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 06:42:37 -0000 That's largely a question of testing and service updates. Apple and = Microsoft, at least for their major applications, could have it in their = next service packs if they chose to. On Feb 8, 2011, at 10:37 PM, Roger J=F8rgensen wrote: > On Tue, Feb 8, 2011 at 11:46 PM, Daniel Roesen wrote: >> On Tue, Feb 08, 2011 at 02:31:13PM -0800, Fred Baker wrote: > >>> If you're worried about Happy Eyeballs tripping up CGN, I submit = that >>> we have a lot more to think about than Happy Eyeballs. >>=20 >> We do. I was/am worried about making the problem even bigger by >> advocating detrimental behaviour (or more precisely: not advocating >> friendly behaviour). >=20 > I think you might overlook another _maybe_ more important point to > consider. This might not be technical but more timedepending. > Will Happy Eyeballs get out in time or not? >=20 > I see people trying to get things perfect, that's great but takes = time, > are we sure there is enough time to get things perfect? > Would a 90% solution work NOW? And in ~6-12months time get a > version 2 out that is 98%? >=20 >=20 >=20 > --=20 >=20 > Roger Jorgensen | > rogerj@gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger@jorgensen.no > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rogerj@gmail.com Tue Feb 8 23:27:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560A03A68F2 for ; Tue, 8 Feb 2011 23:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owVZzh-fr1qA for ; Tue, 8 Feb 2011 23:27:15 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id F28673A68BD for ; Tue, 8 Feb 2011 23:27:14 -0800 (PST) Received: by vws7 with SMTP id 7so3610505vws.31 for ; Tue, 08 Feb 2011 23:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=j/uU9jfy1sVQq3fuo6Gk6KFL8p7jGE2MKLFYPRJHMiw=; b=d9Barl9TBJMbGIKzvDaOk6F7e4Qd7TLmrxG9Q37fmdX2e8zocjf5FrC/K09MIbmVpa +eLIlwgKiZePbCslK30BdPCDrq4gzBmL8FALFHetyDRmtiJsZVu4wCnPq1fYId1aVTBQ TD4cmFw6VMYujkBwf6JEr8TkBYLbpE4kDXUiI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=t0Zv2HqYEViwcquE3o6eIBrMx8X7pFy0RH+eVON8CqB+wYf4Ze/KwUdNHyUuPiIP50 3+snOBcPRJPvMsklZZmT0fz4Oah2xi6SHosXaVP1MEEgb1oL8HYxSPrBVcA1En1Lb5xE 48oh9z1Q5y2VHcOLy94UF74NZIglysooxC22E= MIME-Version: 1.0 Received: by 10.220.201.194 with SMTP id fb2mr4998125vcb.199.1297236443272; Tue, 08 Feb 2011 23:27:23 -0800 (PST) Received: by 10.220.203.137 with HTTP; Tue, 8 Feb 2011 23:27:23 -0800 (PST) In-Reply-To: References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> <20110208215855.GC8815@srv03.cluenet.de> <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> <20110208224653.GA13986@srv03.cluenet.de> Date: Wed, 9 Feb 2011 08:27:23 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 07:27:16 -0000 to correct/update my own post - the maybe most important question, Do we think its usefull? I would say yes. And it can't do much harm that can't be fixed in the next update from any OS provider... ~30days of pain/learning how to do it correct, 90% vs 98%. --- Roger J --- On Wed, Feb 9, 2011 at 7:37 AM, Roger J=F8rgensen wrote: > On Tue, Feb 8, 2011 at 11:46 PM, Daniel Roesen wrote: >> On Tue, Feb 08, 2011 at 02:31:13PM -0800, Fred Baker wrote: > >>> If you're worried about Happy Eyeballs tripping up CGN, I submit that >>> we have a lot more to think about than Happy Eyeballs. >> >> We do. I was/am worried about making the problem even bigger by >> advocating detrimental behaviour (or more precisely: not advocating >> friendly behaviour). > > I think you might overlook another _maybe_ more important point to > consider. This might not be technical but more timedepending. > Will Happy Eyeballs get out in time or not? > > I see people trying to get things perfect, that's great but takes time, > are we sure there is enough time to get things perfect? > Would a 90% solution work NOW? And in ~6-12months time get a > version 2 out that is 98%? > > > > -- > > 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 > --=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 remi.despres@free.fr Wed Feb 9 00:33:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8529F3A6946 for ; Wed, 9 Feb 2011 00:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.095 X-Spam-Level: X-Spam-Status: No, score=0.095 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlGlLxHrCTUK for ; Wed, 9 Feb 2011 00:33:04 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by core3.amsl.com (Postfix) with ESMTP id 9867B3A6945 for ; Wed, 9 Feb 2011 00:33:04 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2204.sfr.fr (SMTP Server) with ESMTP id EF0D77000095; Wed, 9 Feb 2011 09:33:12 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2204.sfr.fr (SMTP Server) with ESMTP id 6FE4F700008E; Wed, 9 Feb 2011 09:33:12 +0100 (CET) X-SFR-UUID: 20110209083312458.6FE4F700008E@msfrf2204.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20110208225706.GB13986@srv03.cluenet.de> Date: Wed, 9 Feb 2011 09:33:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <1297162751.4205.42.camel@shakira.millnert.se> <4D51B4E4.1070405@gmail.com> <20110208225706.GB13986@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 08:33:05 -0000 Le 8 f=E9vr. 2011 =E0 23:57, Daniel Roesen a =E9crit : > ... hy we operators ask to > advocate deprecating 6to4 _now_ so that it will hopefully have gained > some traction when LSNs will get deployed at large - which I expect to > happen in EU in the later 2011 and certainly in 2012. Do you make a difference between (a) 6to4 "disabled by default" (a behavior to be recommended from now = on) (b) 6to4 "deprecated" (banned use of 6to4, even if consciously enabled = where it is found useful) In my understanding, (a) is sufficient. Insisting for (b) wouldn't be useful.. Regards, RD From mohacsi@niif.hu Wed Feb 9 00:50:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6EDB3A6949 for ; Wed, 9 Feb 2011 00:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bejfm3L8nMZk for ; Wed, 9 Feb 2011 00:50:04 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 7F07D3A6885 for ; Wed, 9 Feb 2011 00:50:04 -0800 (PST) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id 351F386C1F; Wed, 9 Feb 2011 09:50:12 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id UaWLCL5f2JOP; Wed, 9 Feb 2011 09:49:56 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 9279786C1B; Wed, 9 Feb 2011 09:49:56 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 615A386C16; Wed, 9 Feb 2011 09:49:56 +0100 (CET) Date: Wed, 9 Feb 2011 09:49:56 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Jack Bates In-Reply-To: <4D5185FD.5070303@brightok.net> Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> <4D515EE7.1080008@brightok.net> <4D516522.9050007@brightok.net> <4BF9DA98-DBD9-4658-A28A-C1463B3808C1@network-heretics.com> <4D518248.3000900@brightok.net> <4D5185FD.5070303@brightok.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 08:50:05 -0000 On Tue, 8 Feb 2011, Jack Bates wrote: > On 2/8/2011 11:56 AM, Mohacsi Janos wrote: >> >> Fix the DNS servers. >> > > They are not my DNS servers to fix. In addition, customers often won't > recognize the problem and just sit at home grumbling about how crappy our > service is. Yes the DNS server is not yours, but you have knowledgable technician at the helpdesk who can reproduce the problem and report to the operator of the remote DNS server. We need: - Educated helpdesk people - coopaeration to resolve th problem There was an initiative (v6fix) few years ago to resolve IPv6 deployment problems: http://v6fix.net/index.html See the publications: http://v6fix.net/bib.html.en We need urgently extend this work.... Best Regards, Janos Mohacsi From mohacsi@niif.hu Wed Feb 9 00:52:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356093A691E for ; Wed, 9 Feb 2011 00:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8Uzk3o5wCpD for ; Wed, 9 Feb 2011 00:52:32 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 4DFBB3A691C for ; Wed, 9 Feb 2011 00:52:32 -0800 (PST) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 6275186C1C; Wed, 9 Feb 2011 09:52:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id 5-Vz0NqDzAis; Wed, 9 Feb 2011 09:52:24 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id C6CC386C13; Wed, 9 Feb 2011 09:52:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id C1F0A86C02; Wed, 9 Feb 2011 09:52:24 +0100 (CET) Date: Wed, 9 Feb 2011 09:52:24 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Jack Bates In-Reply-To: <4D518586.30105@brightok.net> Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <20110207182427.GX44800@Space.Net> <2718CADC-1084-420C-9B1D-61EE9154EA6B@network-heretics.com> <20110207185547.GA44800@Space.Net> <4D504251.4050101@brightok.net> <4D50474D.3030406@brightok.net> <4D51507C.9050409@brightok.net> <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> <4D515EE7.1080008@brightok.net> <4D516522.9050007@brightok.net> <4BF9DA98-DBD9-4658-A28A-C1463B3808C1@network-heretics.com> <4D518248.3000900@brightok.net> <4D518586.30105@brightok.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 08:52:33 -0000 On Tue, 8 Feb 2011, Jack Bates wrote: > > > On 2/8/2011 11:56 AM, Mohacsi Janos wrote: > >> Can you list pathing and peering issues.... If these problems did not >> fixed, then users will stop using that provider.... >> > > Read NANOG archives. There's a long list. Just to hit a big one, No level3 > customer can reach any HE customer (or google for that matter). I believe > Cogent and HE are still divided. There are more, though I'm still waiting on > NSP PE support for v6 from my other transits. Shame on these providers if they don't treat IPv6 as important as IPv4. We reached a point where IPv6 unavoidable. If some provider supports IPv6 poorly, their users will complain and probably change to another one. Best Regards, Janos Mohacsi From mohacsi@niif.hu Wed Feb 9 01:18:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1C23A6940 for ; Wed, 9 Feb 2011 01:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.446 X-Spam-Level: X-Spam-Status: No, score=0.446 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_17=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+NBoDPHJhrM for ; Wed, 9 Feb 2011 01:18:04 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 5CC2D3A6847 for ; Wed, 9 Feb 2011 01:18:03 -0800 (PST) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id A6C6A86C1C; Wed, 9 Feb 2011 10:18:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id lh2bCNfOMQUX; Wed, 9 Feb 2011 10:17:55 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 1D27E85570; Wed, 9 Feb 2011 10:17:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 173CD85088; Wed, 9 Feb 2011 10:17:55 +0100 (CET) Date: Wed, 9 Feb 2011 10:17:54 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: =?ISO-8859-15?Q?Roger_J=F8rgensen?= In-Reply-To: Message-ID: References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> <20110208215855.GC8815@srv03.cluenet.de> <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> <20110208224653.GA13986@srv03.cluenet.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 09:18:05 -0000 On Wed, 9 Feb 2011, Roger J?rgensen wrote: > On Tue, Feb 8, 2011 at 11:46 PM, Daniel Roesen wrote: >> On Tue, Feb 08, 2011 at 02:31:13PM -0800, Fred Baker wrote: > >>> If you're worried about Happy Eyeballs tripping up CGN, I submit that >>> we have a lot more to think about than Happy Eyeballs. >> >> We do. I was/am worried about making the problem even bigger by >> advocating detrimental behaviour (or more precisely: not advocating >> friendly behaviour). > > I think you might overlook another _maybe_ more important point to > consider. This might not be technical but more timedepending. > Will Happy Eyeballs get out in time or not? > > I see people trying to get things perfect, that's great but takes time, > are we sure there is enough time to get things perfect? > Would a 90% solution work NOW? And in ~6-12months time get a > version 2 out that is 98%? As I said earlier happy eyeball idea requires to rewrite every application which is relying on socket calls. The socket is an endpoint of a bidirectional inter-process communication flow. The most important differentiator here is the flow. In happy eyeball you might have dozens of flows initially, which is eventually reduced to 1 flow. This asynchronous connection setup, selective tear down, has to have different API than the current socket API, something like: int tcp_connect(const char *host, const char *serv) It has some early implementation without the asynchronous connection setup and selective tear down from W. Richards Stevens: http://www.kohala.com/start/unpv12e.html From dr@cluenet.de Wed Feb 9 01:25:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B693A695A for ; Wed, 9 Feb 2011 01:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vomO7Qnaq0oW for ; Wed, 9 Feb 2011 01:25:11 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 3DAC13A6955 for ; Wed, 9 Feb 2011 01:25:11 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 53F1E1080BB; Wed, 9 Feb 2011 10:25:19 +0100 (CET) Date: Wed, 9 Feb 2011 10:25:19 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110209092519.GA22042@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> <1297162751.4205.42.camel@shakira.millnert.se> <4D51B4E4.1070405@gmail.com> <20110208225706.GB13986@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 09:25:12 -0000 Hi, On Wed, Feb 09, 2011 at 09:33:11AM +0100, Rémi Després wrote: > > ... hy we operators ask to > > advocate deprecating 6to4 _now_ so that it will hopefully have gained > > some traction when LSNs will get deployed at large - which I expect to > > happen in EU in the later 2011 and certainly in 2012. > > Do you make a difference between > (a) 6to4 "disabled by default" (a behavior to be recommended from now on) > (b) 6to4 "deprecated" (banned use of 6to4, even if consciously enabled where it is found useful) > > In my understanding, (a) is sufficient. Correct, and that's what I'm looking for. > Insisting for (b) wouldn't be useful.. Agreed. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From remi.despres@free.fr Wed Feb 9 01:57:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEBE63A6921 for ; Wed, 9 Feb 2011 01:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.032 X-Spam-Level: X-Spam-Status: No, score=0.032 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_40=-0.185, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdA30Lrh1Jru for ; Wed, 9 Feb 2011 01:57:21 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.21]) by core3.amsl.com (Postfix) with ESMTP id 2A52E3A68BF for ; Wed, 9 Feb 2011 01:57:21 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2311.sfr.fr (SMTP Server) with ESMTP id 9591A700008E; Wed, 9 Feb 2011 10:57:29 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2311.sfr.fr (SMTP Server) with ESMTP id EFF50700008A; Wed, 9 Feb 2011 10:57:28 +0100 (CET) X-SFR-UUID: 20110209095728982.EFF50700008A@msfrf2311.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> Date: Wed, 9 Feb 2011 10:57:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: v6ops v6ops , Daniel Roesen Subject: [v6ops] Disable 6to4 by default but don't deprecate Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 09:57:22 -0000 Le 9 f=E9vr. 2011 =E0 00:34, Keith Moore a =E9crit : > ... There's definitely an ideology that use of 6to4 is somehow not = legitimate and that it's therefore acceptable to sabotage it rather than = to try to fix it. Would you accept a recommendation that, from now on, 6to4 should be = disabled by default. Thus: =20 - Users who know what they do, and keep or turn 6to4 on, won't feel = criticized by IETF - The message being clear enough, completely deprecating 6to4 would = become an unnecessary overreaction. This, I hope, could contribute to bring this discussion to an end. Regards, RD From dr@cluenet.de Wed Feb 9 02:06:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE06F3A696D for ; Wed, 9 Feb 2011 02:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIGhq8kmlEsM for ; Wed, 9 Feb 2011 02:06:13 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 4D4033A6902 for ; Wed, 9 Feb 2011 02:06:12 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id E26FD1080D5; Wed, 9 Feb 2011 11:06:20 +0100 (CET) Date: Wed, 9 Feb 2011 11:06:20 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110209100620.GB22042@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <4D51507C.9050409@brightok.net> <16EA39C2-4534-456E-9223-FD21DCFA5A61@nominum.com> <4D515EE7.1080008@brightok.net> <4D516522.9050007@brightok.net> <4BF9DA98-DBD9-4658-A28A-C1463B3808C1@network-heretics.com> <4D518248.3000900@brightok.net> <4D518586.30105@brightok.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 10:06:13 -0000 On Wed, Feb 09, 2011 at 09:52:24AM +0100, Mohacsi Janos wrote: >> Read NANOG archives. There's a long list. Just to hit a big one, No level3 >> customer can reach any HE customer (or google for that matter). I believe >> Cogent and HE are still divided. There are more, though I'm still waiting >> on NSP PE support for v6 from my other transits. > > Shame on these providers if they don't treat IPv6 as important as IPv4. They do, this is why those effects show up. HE is on a crusade trying to become "tier 1" in IPv6 world (guess why they offer free transit to everyone not quick enough to escape - there ain't such a thing as a free lunch). Level 3 is "tier 1" in IPv4 world and has any intention to maintain that status in IPv6 too, so their peering policies apply to IPv6 just as they do for IPv4. Cogent - is Cogent. They of cause try to maintain their wannabe-"tier 1" status in IPv6 too, so have their interesting disputes with real "tier 1"s every now and then, just like in IPv4. My guess is that L3 doesn't want to have SFI peering with Cogent but Cogent trying to knee-jerk attain that by refusing to buy transit somewhere. All those battling for maintaining or achieving "tier 1" status in IPv6 world will not take a full feed from anyone else so things remain partioned until IPv6 peering landscape has converged to the IPv4 picture. What is being described above IS actually happening BECAUSE those ISPs take IPv6 as serious as IPv4. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From jouni.nospam@gmail.com Wed Feb 9 03:04:32 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9309C3A697A for ; Wed, 9 Feb 2011 03:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdOGGXrkllY2 for ; Wed, 9 Feb 2011 03:04:31 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 78C6E3A6971 for ; Wed, 9 Feb 2011 03:04:31 -0800 (PST) Received: by bwz12 with SMTP id 12so880403bwz.31 for ; Wed, 09 Feb 2011 03:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=HRaMImvEb+JSg5HIjGNvhyGcPKCdA0qkL7fdAwTLm1k=; b=Ej2Oalxwm0ltoGrejIBS6gW8XsUU8+dxWdDJOenEKDP5CJLMMOJNG8GtNVpmetqDv7 slVNBaQuBpaO2uEJKcGdyhDPd2kzXsYe6GqTALMHR/uunTzsLNmg0L8fCdL5ZmWe5Ozx hq6eXW6+B+ehgbkXeDVf5i/Kgs1G/jB69wwqw= 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=uXlPKDrFU010UAmDsdYsWg6P/iR5g7EJVgzeWBf5mbYnDdUBY3+s9cAMzTWZNhPhIj Wgs+kDPYekLPHb6mevLEBQof8ZrceooRpJQe4JH40L/Cyem7iaRRFkgcHy0FJN2RyGaU l1EeMO0nVDCbc8oKSGvoOgMB+4tlKQK7xhhDc= Received: by 10.204.116.206 with SMTP id n14mr4978602bkq.65.1297249480134; Wed, 09 Feb 2011 03:04:40 -0800 (PST) Received: from a88-112-143-79.elisa-laajakaista.fi (a88-112-143-79.elisa-laajakaista.fi [88.112.143.79]) by mx.google.com with ESMTPS id x38sm123902bkj.13.2011.02.09.03.04.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 03:04:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <59980476-D8F4-4AA0-976F-9DCECB5550DB@apple.com> Date: Wed, 9 Feb 2011 13:04:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1DBC366D-F227-466D-9C07-F6B73279E6C1@gmail.com> References: <59980476-D8F4-4AA0-976F-9DCECB5550DB@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1078) Cc: draft-korhonen-v6ops-3gpp-eps.authors@tools.ietf.org, IPv6 Operations Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 11:04:32 -0000 Hi James, On Feb 9, 2011, at 4:43 AM, james woodyatt wrote: > On Feb 8, 2011, at 15:58, james woodyatt wrote: >>=20 >> Okay. Does that mean that the IID signaled in the PDN connection = setup is *NOT eligible for use with the RFC 4429 optimistic DAD = algorithm? Why wouldn't it be? If that's the case, then surely the = draft should be amended to explain that! >=20 > Ah. I see my goof. The draft says this: >=20 >> The details of the 3GPP link-model and address configuration is = described in Section 11.2.1.3.2a of [3GPP.29.061]. >=20 > That document elaborates: >=20 >> Since the GGSN guarantees that the Prefix is unique, the MS does not = need to perform any Duplicate Address Detection on addresses it creates. = That is, the 'DupAddrDetectTransmits' variable in the MS should have a = value of zero. If the MS finds more than one Prefix in the Router = Advertisement message, it shall only consider the first one and silently = discard the others. The GGSN shall not generate any globally unique IPv6 = addresses for itself using the Prefix assigned to the MS in the Router = Advertisement. >=20 > It seems to me like this draft would be improved by spelling that out = explicitly here too. Ok. Will check it (the new rev has been lingering on my hdd for quite = some time already.. shame on me ;) >=20 > On a related note, I didn't find any specific language in the 3GPP = draft explaining what to do when the PIO option in the RA message = contains a prefix length shorter than 64 bits. Seems like an oversight. = One assumes that zero-extending to 64 bits is acceptable, but a = normative instruction would be better. The 3GPP specs assume normal IPv6 stack behavior in that case i.e. be = silent about it. What you have exactly in mind here? SLAAC would work = only for /64 and since 3GPP link model only supports a single prefix, = having other prefixes shorter than /64 does not make much use. (well I = have pushed multiple prefixes over a PDP context and made the mobile = configure multiple global addresses but that is different and not really = supported) - Jouni >=20 >=20 > -- > james woodyatt > member of technical staff, core os networking >=20 >=20 >=20 From pekkas@netcore.fi Wed Feb 9 03:17:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9BC3A6945 for ; Wed, 9 Feb 2011 03:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcFlLfzAYNLe for ; Wed, 9 Feb 2011 03:17:26 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 88CB63A67DF for ; Wed, 9 Feb 2011 03:17:25 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p19BHVuN016404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Feb 2011 13:17:31 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p19BHVhE016401; Wed, 9 Feb 2011 13:17:31 +0200 Date: Wed, 9 Feb 2011 13:17:31 +0200 (EET) From: Pekka Savola To: Daniel Roesen In-Reply-To: <20110208185049.GB28211@srv03.cluenet.de> Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: v6ops@ietf.org Subject: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 11:17:26 -0000 On Tue, 8 Feb 2011, Daniel Roesen wrote: > And 6to4 brokeness and thus IPv6 brokeness will skyrocket as soon as > fast growing residential ISP will start to deploy LSN. That will certainly happen if the ISP is natting between two public address spaces. But I don't think LSN would do that by definition? If the ISP switches the user to use a private IP space, 6to4 usage will just stop but it won't break. Let's keep these two cases clearly distinct. Otherwise, let's drop this "IPv6 breaks when residential ISP deploys LSN". Am I missing something? -- 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 mohsen.souissi@nic.fr Wed Feb 9 03:28:18 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4CEC3A695E for ; Wed, 9 Feb 2011 03:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3vQqJYcXbOY for ; Wed, 9 Feb 2011 03:28:18 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id 750583A6945 for ; Wed, 9 Feb 2011 03:28:17 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id ED61D1C0101 for ; Wed, 9 Feb 2011 12:28:25 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id E96711C0027 for ; Wed, 9 Feb 2011 12:28:25 +0100 (CET) Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by relay2.nic.fr (Postfix) with ESMTP id E71327B0037 for ; Wed, 9 Feb 2011 12:28:25 +0100 (CET) Received: from kerkenna.nic.fr (localhost [127.0.0.1]) by kerkenna.nic.fr (8.14.4/8.13.8) with ESMTP id p19BSPvl087379 for ; Wed, 9 Feb 2011 12:28:25 +0100 (CET) (envelope-from souissi@kerkenna.nic.fr) Received: (from souissi@localhost) by kerkenna.nic.fr (8.14.4/8.14.2/Submit) id p19BSPil087378 for v6ops@ietf.org; Wed, 9 Feb 2011 12:28:25 +0100 (CET) (envelope-from souissi) Date: Wed, 9 Feb 2011 12:28:25 +0100 From: Mohsen Souissi To: IPv6 Operations Message-ID: <20110209112825.GD86059@kerkenna.nic.fr> References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 11:28:18 -0000 I agree with Rémi's comments below. Let's get rid of 6to4 in order to get a cleaner IPv6 deployment, even taking the risk of breaking some (poorly) working connections. Regards, Mohsen. On 08 Feb, Rémi Després wrote: | Brian, | | I find Ole's proposal interesting *for the new phase we are entering*, i.e. one where: | - native IPv6 adresses are progressively deployed | - 6to4, that has been extensively use despite its limitations, should now recede | | | Le 8 févr. 2011 à 10:14, Ole Troan a écrit : | > ... 6to4 does not in any way accelerate IPv6 deployment. | > | > if the draft can achieve that: | > - CPE and hosts vendors stop enabling 6to4 by default | | +1 | | > - no-one advertises 6to4 AAAA records in DNS | | Except maybe where 6to4 is the only available incoming connectivity, but that's minor. | | > - 6to4 is put at the absolute bottom (with Teredo) in the SAS/DAS algorithms. | | Ideally, RFC 3484bis would do it. | | > - people stop considering 6to4 as a valid transitioning mechanism; there are too many choices already. | | At least not a mechanism to be considered for new deployments. | | Regards, | RD From victor.kuarsingh@gmail.com Wed Feb 9 05:07:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6DF3A69C3 for ; Wed, 9 Feb 2011 05:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdcSfYwCxbrc for ; Wed, 9 Feb 2011 05:07:39 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 82F1E3A69AB for ; Wed, 9 Feb 2011 05:07:39 -0800 (PST) Received: by iym1 with SMTP id 1so142040iym.31 for ; Wed, 09 Feb 2011 05:07:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=LI21gPSQW8YmH68l1ElegSE0G0M0KWHiRHvDnKy2RqI=; b=qrQL79hk1giNauXH2hMy5FWW2PwayDIDPVlbMA4jgphEGkMrHn1/Vwc+SXKrFLJ4C5 SbIO1NogDlpSRAsSTCjcITP/+Ljd5D/44bYSdBc2VCP+rpKy4mVLwVYm0HUMtCThQfTj 8RhS44IxfaZ31tlnx67nbtQKX7pcmjPx3yQB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=m+xQmSf5Fbo3M9L+IihtV7p2MwFbleXA8shqUJ4kFZ5Ic+l+f6RcCFKzmJMsmJ6Ygd h7E6dnOOCGHLHXiVSd17eQvNV9JdjL24OpU32m2VVzmDaABtyWTQP8qo51HgfyuXshzf bFGKx/L0AvMugft49hzEaoigbot4BNe4c1eVo= Received: by 10.42.222.70 with SMTP id if6mr20421687icb.224.1297256868987; Wed, 09 Feb 2011 05:07:48 -0800 (PST) Received: from [192.168.200.100] (CPE00259c38b213-CM001a666bafe6.cpe.net.cable.rogers.com [99.229.11.38]) by mx.google.com with ESMTPS id z4sm275504ibg.19.2011.02.09.05.07.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 05:07:47 -0800 (PST) User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 09 Feb 2011 08:07:45 -0500 From: Victor Kuarsingh To: Pekka Savola , Daniel Roesen Message-ID: Thread-Topic: [v6ops] LSN breaking 6to4 Thread-Index: AcvIWldzDMgI3o7FRka+ev7ux3epbw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 13:07:40 -0000 Pekka, On 09/02/11 6:17 AM, "Pekka Savola" wrote: > On Tue, 8 Feb 2011, Daniel Roesen wrote: >> And 6to4 brokeness and thus IPv6 brokeness will skyrocket as soon as >> fast growing residential ISP will start to deploy LSN. > > That will certainly happen if the ISP is natting between two public > address spaces. But I don't think LSN would do that by definition? I don't there there is a "default" position among how various operators will implement CGN/LSN. Most seem to have their own strategies (which many don't talk about). > > If the ISP switches the user to use a private IP space, 6to4 usage > will just stop but it won't break. Let's keep these two cases clearly > distinct. I don't think private address space is viable for all operators. Many have already used up this address space and others seem to have challenges using is for other reasons (i.e. Home network overlap etc) > > Otherwise, let's drop this "IPv6 breaks when residential ISP deploys > LSN". I do see a need to discuss and understand how the community will deal with 6to4 brokenness related to LSN (since this is likely to proliferate soon and after IPv4 exhaustion in operator networks). > > Am I missing something? Victor K From pekkas@netcore.fi Wed Feb 9 05:13:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56DF23A69CA for ; Wed, 9 Feb 2011 05:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ll+AC5QJHZwx for ; Wed, 9 Feb 2011 05:13:40 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id E8B4A3A69C7 for ; Wed, 9 Feb 2011 05:13:39 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p19DDjDe019364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Feb 2011 15:13:45 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p19DDjTr019361; Wed, 9 Feb 2011 15:13:45 +0200 Date: Wed, 9 Feb 2011 15:13:45 +0200 (EET) From: Pekka Savola To: Victor Kuarsingh In-Reply-To: Message-ID: References: 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.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 13:13:41 -0000 On Wed, 9 Feb 2011, Victor Kuarsingh wrote: >> Otherwise, let's drop this "IPv6 breaks when residential ISP deploys >> LSN". > > I do see a need to discuss and understand how the community will deal with > 6to4 brokenness related to LSN (since this is likely to proliferate soon and > after IPv4 exhaustion in operator networks). In order to conduct technical discussion, we will need to know how LSN is implemented. Some facts that I've gleaned: - TMO's approach of hijacking public address space for inner addresses indeed "breaks" 6to4. - When LSN is deployed with private inner addresses, 6to4 does not break. Is the rest just speculation? -- 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 moore@network-heretics.com Wed Feb 9 05:32:18 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D723A69AD for ; Wed, 9 Feb 2011 05:32:18 -0800 (PST) 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.064, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN1vsnttVrMq for ; Wed, 9 Feb 2011 05:32:17 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 126983A695D for ; Wed, 9 Feb 2011 05:32:15 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PnA9g-0003d6-Hx; Wed, 09 Feb 2011 08:32:25 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: Date: Wed, 9 Feb 2011 08:32:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <990AC7E2-62A1-40A5-870E-700778743055@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9404d288413c11b94999fc1e8a7f11b72b7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops v6ops , Daniel Roesen Subject: Re: [v6ops] Disable 6to4 by default but don't deprecate Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 13:32:18 -0000 On Feb 9, 2011, at 4:57 AM, R=E9mi Despr=E9s wrote: > Le 9 f=E9vr. 2011 =E0 00:34, Keith Moore a =E9crit : >=20 >> ... There's definitely an ideology that use of 6to4 is somehow not = legitimate and that it's therefore acceptable to sabotage it rather than = to try to fix it. >=20 > Would you accept a recommendation that, from now on, 6to4 should be = disabled by default. no. I think this is very premature. What I do accept is that if an ISP imposes NAT on its customers, there = should be some well-defined mechanism to signal that to hosts using = 6to4, so that those hosts can (a) stop trying to use 6to4 on that link, = and (b) provide a useful error message to their users. Keith From moore@network-heretics.com Wed Feb 9 05:39:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39D633A695D for ; Wed, 9 Feb 2011 05:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDnTEfDHyuV9 for ; Wed, 9 Feb 2011 05:39:44 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 759EB3A69AD for ; Wed, 9 Feb 2011 05:39:44 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PnAGr-0006GR-Tf; Wed, 09 Feb 2011 08:39:52 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Wed, 9 Feb 2011 08:39:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> To: Pekka Savola X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9408f682da33aef60ab8cf928bce99240fd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 13:39:45 -0000 On Feb 9, 2011, at 6:17 AM, Pekka Savola wrote: > On Tue, 8 Feb 2011, Daniel Roesen wrote: >> And 6to4 brokeness and thus IPv6 brokeness will skyrocket as soon as = fast growing residential ISP will start to deploy LSN. >=20 > That will certainly happen if the ISP is natting between two public = address spaces. But I don't think LSN would do that by definition? >=20 > If the ISP switches the user to use a private IP space, 6to4 usage = will just stop but it won't break. Let's keep these two cases clearly = distinct. >=20 > Otherwise, let's drop this "IPv6 breaks when residential ISP deploys = LSN". >=20 > Am I missing something? It seems to me that if an ISP starts giving RFC 1918 addresses to its = customers, that's going to cause breakage too. It's going to break = different things than if it had assigned those customers addresses = belonging to someone else. I'm not entirely sure which is worse, but = intuitively the former seems worse to me. And while I agree that the two cases are distinct, using any kind of NAT = breaks 6to4. And if that's the only means of v6 access available to the = customer, the effect of LSN _is_ to break IPv6. Keith From moore@network-heretics.com Wed Feb 9 05:42:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97E83A695D for ; Wed, 9 Feb 2011 05:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYk5-yboP1uW for ; Wed, 9 Feb 2011 05:42:15 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id D6AF93A68D4 for ; Wed, 9 Feb 2011 05:42:15 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PnAJL-0007uk-PN; Wed, 09 Feb 2011 08:42:24 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-47--1023327509 From: Keith Moore In-Reply-To: Date: Wed, 9 Feb 2011 08:42:15 -0500 Message-Id: References: To: Pekka Savola X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940ebad8ddd2aad3d1c13589c90c8bd7864350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 13:42:16 -0000 --Apple-Mail-47--1023327509 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 9, 2011, at 8:13 AM, Pekka Savola wrote: >=20 > - When LSN is deployed with private inner addresses, 6to4 does not > break. Incorrect. 6to4 is disabled in this circumstance. Arguably it's = cleaner than having it "break" by being assigned IPv4 addresses that = aren't reachable from elsewhere, but the ability to use IPv6 is lost in = either case. Keith --Apple-Mail-47--1023327509 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Feb 9, 2011, at 8:13 AM, Pekka Savola wrote:

- When LSN is deployed with private inner addresses, 6to4 does not
 break.

Incorrect.  6to4 is disabled in this circumstance.  Arguably it's cleaner than having it "break" by being assigned IPv4 addresses that aren't reachable from elsewhere, but the ability to use IPv6 is lost in either case.

Keith

--Apple-Mail-47--1023327509-- From pekkas@netcore.fi Wed Feb 9 05:51:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 371943A69B8 for ; Wed, 9 Feb 2011 05:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vwvq8l1beCjB for ; Wed, 9 Feb 2011 05:51:23 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id F251E3A69AD for ; Wed, 9 Feb 2011 05:51:22 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p19DpSHG020148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Feb 2011 15:51:28 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p19DpSsq020144; Wed, 9 Feb 2011 15:51:28 +0200 Date: Wed, 9 Feb 2011 15:51:28 +0200 (EET) From: Pekka Savola To: Keith Moore In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-881597855-1297259488=:20003" X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 13:51:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-881597855-1297259488=:20003 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 9 Feb 2011, Keith Moore wrote: > On Feb 9, 2011, at 8:13 AM, Pekka Savola wrote: > - When LSN is deployed with private inner addresses, 6to4 does not >  break. > > Incorrect.  6to4 is disabled in this circumstance.  Arguably it's cleaner than having it "break" by being assigned IPv4 addresses that aren't reachable from elsewhere, but the ability > to use IPv6 is lost in either case. Let's stop using the word "break" then. It doesn't appear to be useful in technical discussion. One could for example say that 6to4 is either "blackholed" or "turned off". I agree it's unfortunate that 6to4 would get turned off, but 6to4 implementations will get disabled with private IPv4 addresses. This is MUCH better than IPv6 blackholing when 6to4 is enabled on end-systems but blocked in the network. Systems that end up behind LSN and private addresses also have the option of starting to use Teredo or another transition mechanism that can punch through LSN. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-881597855-1297259488=:20003-- From Fred.L.Templin@boeing.com Wed Feb 9 05:56:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBDDF3A68D4 for ; Wed, 9 Feb 2011 05:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kn4gpRz2TECq for ; Wed, 9 Feb 2011 05:56:49 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id AB5A63A69AB for ; Wed, 9 Feb 2011 05:56:49 -0800 (PST) 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 p19DufSF006540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Feb 2011 05:56:44 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p19Dufsd006505; Wed, 9 Feb 2011 07:56:41 -0600 (CST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p19DueN0006489 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 9 Feb 2011 07:56:41 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Wed, 9 Feb 2011 05:56:40 -0800 From: "Templin, Fred L" To: Pekka Savola , Keith Moore Date: Wed, 9 Feb 2011 05:56:39 -0800 Thread-Topic: [v6ops] LSN breaking 6to4 Thread-Index: AcvIYHxo+XXrgz0vSO6lU5lj68RiRAAABmuA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Daniel Roesen Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 13:56:50 -0000 Hi Pekka,=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Pekka Savola > Sent: Wednesday, February 09, 2011 5:51 AM > To: Keith Moore > Cc: v6ops@ietf.org; Daniel Roesen > Subject: Re: [v6ops] LSN breaking 6to4 >=20 > On Wed, 9 Feb 2011, Keith Moore wrote: > > On Feb 9, 2011, at 8:13 AM, Pekka Savola wrote: > > - When LSN is deployed with private inner addresses,=20 > 6to4 does not > > =A0break. > >=20 > > Incorrect. =A06to4 is disabled in this circumstance. =A0 > Arguably it's cleaner than having it "break" by being=20 > assigned IPv4 addresses that aren't reachable from elsewhere,=20 > but the ability > > to use IPv6 is lost in either case. >=20 > Let's stop using the word "break" then. It doesn't appear to be=20 > useful in technical discussion. One could for example say that 6to4=20 > is either "blackholed" or "turned off". >=20 > I agree it's unfortunate that 6to4 would get turned off, but 6to4=20 > implementations will get disabled with private IPv4=20 > addresses. This is=20 > MUCH better than IPv6 blackholing when 6to4 is enabled on end-systems=20 > but blocked in the network. Systems that end up behind LSN and=20 > private addresses also have the option of starting to use Teredo or=20 > another transition mechanism that can punch through LSN. IRON qualifies as "another mechanism that can punch through LSN", but it is more than just a transition tool: http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt IRON enables entire IPv6 networks behind LSNs, and not just individual hosts. Thanks - Fred fred.l.templin@boeing.com=20 =20 > --=20 > 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 Wesley.E.George@sprint.com Wed Feb 9 06:00:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D823A69CF for ; Wed, 9 Feb 2011 06:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8RvRexsjhp5 for ; Wed, 9 Feb 2011 06:00:06 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1outboundpool.messaging.microsoft.com [216.32.181.182]) by core3.amsl.com (Postfix) with ESMTP id 93E983A68D4 for ; Wed, 9 Feb 2011 06:00:05 -0800 (PST) Received: from mail62-ch1-R.bigfish.com (216.32.181.169) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.8; Wed, 9 Feb 2011 14:00:14 +0000 Received: from mail62-ch1 (localhost.localdomain [127.0.0.1]) by mail62-ch1-R.bigfish.com (Postfix) with ESMTP id E510219B00B8; Wed, 9 Feb 2011 14:00:14 +0000 (UTC) X-SpamScore: -34 X-BigFish: VS-34(zz98dN9371Pzz1202hzz8275dh1033ILz2fh2a8h668h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm2.corp.sprint.com; RD:smtpls2.sprint.com; EFVD:NLI Received: from mail62-ch1 (localhost.localdomain [127.0.0.1]) by mail62-ch1 (MessageSwitch) id 1297260014697173_1552; Wed, 9 Feb 2011 14:00:14 +0000 (UTC) Received: from CH1EHSMHS032.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail62-ch1.bigfish.com (Postfix) with ESMTP id 9A3195804C; Wed, 9 Feb 2011 14:00:14 +0000 (UTC) Received: from plsasdm2.corp.sprint.com (144.230.168.26) by CH1EHSMHS032.bigfish.com (10.43.70.32) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 9 Feb 2011 14:00:13 +0000 Received: from PLSWEH01.ad.sprint.com (PLSWEH01.corp.sprint.com [144.226.242.129]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p19E0Bpb030813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Feb 2011 08:00:12 -0600 Received: from PDAWM12B.ad.sprint.com ([fe80::64c8:fd69:1029:79b0]) by PLSWEH01.ad.sprint.com ([2002:90e2:f281::90e2:f281]) with mapi id 14.01.0270.001; Wed, 9 Feb 2011 08:00:11 -0600 From: "George, Wes E [NTK]" To: Keith Moore , Pekka Savola Thread-Topic: [v6ops] LSN breaking 6to4 Thread-Index: AQHLyF86G9HvK9m7/k6re8wJjFuhoJP5L1LA Date: Wed, 9 Feb 2011 14:00:10 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E367A7E@PDAWM12B.ad.sprint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.24] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002D_01CBC837.C1094DC0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "v6ops@ietf.org" , Daniel Roesen Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 14:00:09 -0000 ------=_NextPart_000_002D_01CBC837.C1094DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Keith Moore Sent: Wednesday, February 09, 2011 8:42 AM On Feb 9, 2011, at 8:13 AM, Pekka Savola wrote: >- When LSN is deployed with private inner addresses, 6to4 does not >break. >Incorrect. =A06to4 is disabled in this circumstance. =A0Arguably it's = cleaner than having it "break" by being assigned IPv4 addresses that >aren't reachable from elsewhere, but = the ability to use IPv6 is lost in either case. [WEG] as much as I=92d love for some majority (or even a non-trivial = minority) of my customers to notice that 6to4 is broken or has disabled itself due to being behind a = CGN/NAT444 instance (because it would mean that I have the same non-trivial minority *using* IPv6), = I=92m pretty sure that=92s going to be the least of my problems. As much as I want to see us not break or otherwise prevent 6to4 from = being used, I do not believe that the fact that 6to4 breaks will be a reason for any carrier to = deviate from deploying CGN if it is necessary for the continued function of the rest of the IPv4 = applications that their customers need to use day to day.=20 Much has already been said about the fact that CGN is not a great = solution, there are even drafts (donley) that cover some testing that's been done regarding just how bad = it might be. We already have a draft focused on ways to make 6to4 suck less. Perhaps instead of = rehashing the =93CGN=92s are bad, m=92kay?=94 argument for the umpteenth time, we could acknowledge, = move on, and focus on improving said draft to limit the collateral damage? Wes George ------=_NextPart_000_002D_01CBC837.C1094DC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDITCCAx0CAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB8DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAyMDkxNDAwMDlaMCMGCSqGSIb3DQEJBDEWBBS2cTjRBaWe D6VGzoDXE0nNgzhRlDBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjCBlwYJKwYB BAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJp bnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNl IElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJEAILMYGJoIGGMHgx EzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/Is ZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRo b3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYAkaV1+lAOOf4jCDUoHT68AwV/P//63 tpWRwi8m78ap78IY2xopu43nvt1As5blnM+GLBBOfN66Ca7ak0EdLHmU2WXSwfzYy0jkLPYE9d6A FSaeciX6blTuCpqa97B1+fYWEm0g7NQqdENUxgWRD/eTSXOaTgU67ATxhDGA0m4Q9AAAAAAAAA== ------=_NextPart_000_002D_01CBC837.C1094DC0-- From moore@network-heretics.com Wed Feb 9 06:03:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE1A3A69D2 for ; Wed, 9 Feb 2011 06:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzvhWgc1-dKn for ; Wed, 9 Feb 2011 06:03:13 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id DE8BE3A69CC for ; Wed, 9 Feb 2011 06:03:12 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PnAdb-0004xh-VF; Wed, 09 Feb 2011 09:03:20 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Wed, 9 Feb 2011 09:03:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Pekka Savola X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9402ed6c8fc43e916cc85bb965ca59e5a29350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 14:03:13 -0000 On Feb 9, 2011, at 8:51 AM, Pekka Savola wrote: > On Wed, 9 Feb 2011, Keith Moore wrote: >> On Feb 9, 2011, at 8:13 AM, Pekka Savola wrote: >> - When LSN is deployed with private inner addresses, 6to4 does = not >> break. >> Incorrect. 6to4 is disabled in this circumstance. Arguably it's = cleaner than having it "break" by being assigned IPv4 addresses that = aren't reachable from elsewhere, but the ability >> to use IPv6 is lost in either case. >=20 > Let's stop using the word "break" then. It doesn't appear to be = useful in technical discussion. One could for example say that 6to4 is = either "blackholed" or "turned off". >=20 > I agree it's unfortunate that 6to4 would get turned off, but 6to4 = implementations will get disabled with private IPv4 addresses. This is = MUCH better than IPv6 blackholing when 6to4 is enabled on end-systems = but blocked in the network. It's better if the only thing that you're considering is the effect of = this decision (private vs. non-routable public addresses) on 6to4. It's = not clear that it's better overall. > Systems that end up behind LSN and private addresses also have the = option of starting to use Teredo or another transition mechanism that = can punch through LSN. None of these systems are as widely deployed, or as easily available, as = 6to4. Keith From remi.despres@free.fr Wed Feb 9 06:07:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8883A69C2 for ; Wed, 9 Feb 2011 06:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_05=-1.11, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4lQbdfLI-Ab for ; Wed, 9 Feb 2011 06:07:56 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by core3.amsl.com (Postfix) with ESMTP id 3414D3A69AD for ; Wed, 9 Feb 2011 06:07:56 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id 120867000090; Wed, 9 Feb 2011 15:08:05 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id 9BDB2700009F; Wed, 9 Feb 2011 15:08:04 +0100 (CET) X-SFR-UUID: 20110209140804638.9BDB2700009F@msfrf2116.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <990AC7E2-62A1-40A5-870E-700778743055@network-heretics.com> Date: Wed, 9 Feb 2011 15:08:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <990AC7E2-62A1-40A5-870E-700778743055@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: v6ops v6ops , Daniel Roesen Subject: Re: [v6ops] Disable 6to4 by default but don't deprecate Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 14:07:57 -0000 Le 9 f=E9vr. 2011 =E0 14:32, Keith Moore a =E9crit : > On Feb 9, 2011, at 4:57 AM, R=E9mi Despr=E9s wrote: >=20 >> Le 9 f=E9vr. 2011 =E0 00:34, Keith Moore a =E9crit : >>=20 >>> ... There's definitely an ideology that use of 6to4 is somehow not = legitimate and that it's therefore acceptable to sabotage it rather than = to try to fix it. >>=20 >> Would you accept a recommendation that, from now on, 6to4 should be = disabled by default. >=20 > no. I think this is very premature. >=20 > What I do accept is that if an ISP imposes NAT on its customers, there = should be some well-defined mechanism to signal that to hosts using = 6to4, so that those hosts can (a) stop trying to use 6to4 on that link, = and (b) provide a useful error message to their users. You propose deployment of a new mechanism whose only purpose is to = mitigate problems that ordinary users who have 6to4 disabled don't = experience. This doesn't seem realistic to me. And you ask not only to be free to enable 6to4 for your applications, = but you also insist that some other users, who don't care about these = applications, have to endure some broken connectivities. I can't agree with this approach. Sorry. RD From moore@network-heretics.com Wed Feb 9 06:12:07 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7223A69CD for ; Wed, 9 Feb 2011 06:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Py2gBAYFXCk2 for ; Wed, 9 Feb 2011 06:12:07 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 005E53A69C0 for ; Wed, 9 Feb 2011 06:12:06 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PnAmD-0005EX-BD; Wed, 09 Feb 2011 09:12:15 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Keith Moore In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E367A7E@PDAWM12B.ad.sprint.com> Date: Wed, 9 Feb 2011 09:11:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54E900DC635DAB4DB7A6D799B3C4CD8E367A7E@PDAWM12B.ad.sprint.com> To: "George, Wes E [NTK]" X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94053401acac5811f2218b7e7e5adc49b41350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: "v6ops@ietf.org" , Daniel Roesen Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 14:12:08 -0000 On Feb 9, 2011, at 9:00 AM, George, Wes E [NTK] wrote: > As much as I want to see us not break or otherwise prevent 6to4 from = being used, I do not believe > that the fact that 6to4 breaks will be a reason for any carrier to = deviate from deploying CGN if it > is necessary for the continued function of the rest of the IPv4 = applications that their customers > need to use day to day.=20 Nor I. Nor would I even suggest that they do so. As bad as CGN is, = it's far better than no IPv4 access at all. And clearly it's important = to continue providing access to at least the IPv4 services that can = manage to work over NAT. (I've said for years that the web and email = would be the _last_ services to migrate to v6, because they are so = entrenched, and because they more-or-less work fine even over NAT. So = in my estimation, CGN will be needed for many years to come....though = I'd love to be proven wrong.) But I do believe that because it breaks 6to4, that CGN can have a = chilling effect on IPv6 deployment, and I don't think that's a good = thing. Which is why I think that operators need to be trying very hard = to get native v6 lit up for their customers at the same time as, or = ideally before, they're forced to impose CGN.=20 (And I don't doubt that most operators are now working on rolling out v6 = in addition to CGN, but it's not clear to me whether they see a need to = coordinate those two.) > Much has already been said about the fact that CGN is not a great = solution, there are even drafts > (donley) that cover some testing that's been done regarding just how = bad it might be. We already > have a draft focused on ways to make 6to4 suck less. Perhaps instead = of rehashing the =93CGN=92s are > bad, m=92kay?=94 argument for the umpteenth time, we could = acknowledge, move on, and focus on improving > said draft to limit the collateral damage? I actually think we are moving on, it's just that a lot of emails have = been exchanged and it takes some time for people to get around to = reading them and noticing the change. Keith From moore@network-heretics.com Wed Feb 9 06:18:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5413A69CF for ; Wed, 9 Feb 2011 06:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYVAABNvp0FQ for ; Wed, 9 Feb 2011 06:18:41 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 9FFF23A699A for ; Wed, 9 Feb 2011 06:18:41 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PnAsb-0007TK-13; Wed, 09 Feb 2011 09:18:51 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: Date: Wed, 9 Feb 2011 09:18:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <990AC7E2-62A1-40A5-870E-700778743055@network-heretics.com> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9406abf22ba6b70667fe1b30688bf90ce57350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops v6ops , Daniel Roesen Subject: Re: [v6ops] Disable 6to4 by default but don't deprecate Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 14:18:42 -0000 On Feb 9, 2011, at 9:08 AM, R=E9mi Despr=E9s wrote: > Le 9 f=E9vr. 2011 =E0 14:32, Keith Moore a =E9crit : >=20 >> On Feb 9, 2011, at 4:57 AM, R=E9mi Despr=E9s wrote: >>=20 >>> Le 9 f=E9vr. 2011 =E0 00:34, Keith Moore a =E9crit : >>>=20 >>>> ... There's definitely an ideology that use of 6to4 is somehow not = legitimate and that it's therefore acceptable to sabotage it rather than = to try to fix it. >>>=20 >>> Would you accept a recommendation that, from now on, 6to4 should be = disabled by default. >>=20 >> no. I think this is very premature. >>=20 >> What I do accept is that if an ISP imposes NAT on its customers, = there should be some well-defined mechanism to signal that to hosts = using 6to4, so that those hosts can (a) stop trying to use 6to4 on that = link, and (b) provide a useful error message to their users. >=20 > You propose deployment of a new mechanism whose only purpose is to = mitigate problems that ordinary users who have 6to4 disabled don't = experience. > This doesn't seem realistic to me. Well, I'm hoping that ICMP is sufficient, and that mere configuration of = existing hardware is enough to implement the new mechanism on the = provider side. =20 > And you ask not only to be free to enable 6to4 for your applications, = but you also insist that some other users, who don't care about these = applications, have to endure some broken connectivities. It seems to me that you're the one asking for things to be broken. = Given that a number of platforms have been automatically enabling 6to4 = for awhile now, to me it seems reasonable to expect that there are = applications and users that depend on this. Is it really reasonable to = expect those users to have to know to explicitly turn on 6to4 from here = on out? I think a host should be able to determine what kinds of network access = are available to it, and enable those kinds of access, without explicit = configuration by the user or administrator. =20 Keith From jhw@apple.com Wed Feb 9 06:25:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29C23A69D2 for ; Wed, 9 Feb 2011 06:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZlrCfyiUfv2 for ; Wed, 9 Feb 2011 06:25:39 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 1F4333A69DA for ; Wed, 9 Feb 2011 06:25:39 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id B6E4BCDB58E8 for ; Wed, 9 Feb 2011 06:25:48 -0800 (PST) X-AuditID: 1180711d-b7c12ae00000228a-64-4d52a3ecedbd Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay13.apple.com (Apple SCV relay) with SMTP id 54.0E.08842.CE3A25D4; Wed, 9 Feb 2011 06:25:48 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.153.48.182] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LGC0047NTF0ZN40@gertie.apple.com> for v6ops@ietf.org; Wed, 09 Feb 2011 06:25:48 -0800 (PST) From: james woodyatt In-reply-to: <1DBC366D-F227-466D-9C07-F6B73279E6C1@gmail.com> Date: Wed, 09 Feb 2011 06:25:47 -0800 Message-id: <2B7DCEF4-2977-4087-86D3-49130A2A1DF5@apple.com> References: <59980476-D8F4-4AA0-976F-9DCECB5550DB@apple.com> <1DBC366D-F227-466D-9C07-F6B73279E6C1@gmail.com> To: jouni korhonen X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: draft-korhonen-v6ops-3gpp-eps.authors@tools.ietf.org, IPv6 Operations Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 14:25:40 -0000 On Feb 9, 2011, at 03:04, jouni korhonen wrote: > since 3GPP link model only supports a single prefix, having other prefixes shorter than /64 does not make much use. I was trying to point out that the 3GPP spec says what a UE node shall do if the number of advertised prefixes doesn't match the link model, but it doesn't say what to do if the advertised prefix length doesn't match the link model. It's an exception case, but the devil lurks in details like that. One hopes the 3GPP people can settle it so that IETF doesn't have to do it. -- james woodyatt member of technical staff, core os networking From simon.perreault@viagenie.ca Wed Feb 9 06:36:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B33E13A69F3 for ; Wed, 9 Feb 2011 06:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUHcRhZ8GJXJ for ; Wed, 9 Feb 2011 06:36:00 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 39BE83A69F2 for ; Wed, 9 Feb 2011 06:35:58 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0B96E20F55 for ; Wed, 9 Feb 2011 09:36:07 -0500 (EST) Message-ID: <4D52A656.3090108@viagenie.ca> Date: Wed, 09 Feb 2011 09:36:06 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: v6ops@ietf.org References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> <20110208215855.GC8815@srv03.cluenet.de> <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> <20110208224653.GA13986@srv03.cluenet.de> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 14:36:01 -0000 On 2011-02-09 01:37, Roger Jørgensen wrote: > I think you might overlook another _maybe_ more important point to > consider. This might not be technical but more timedepending. > Will Happy Eyeballs get out in time or not? Happy eyeballs is already out. There are implementations out there that predate the draft. The draft is actually documenting and encouraging existing practice. 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 teemu.savolainen@nokia.com Wed Feb 9 06:48:47 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051263A69E3 for ; Wed, 9 Feb 2011 06:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KChqSXD+yw+X for ; Wed, 9 Feb 2011 06:48:46 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id CCB383A6405 for ; Wed, 9 Feb 2011 06:48:45 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p19EmCc0019882; Wed, 9 Feb 2011 16:48:53 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 16:48:24 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 9 Feb 2011 15:48:23 +0100 Received: from 008-AM1MPN1-016.mgdnok.nokia.com ([169.254.6.185]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi; Wed, 9 Feb 2011 15:48:23 +0100 From: To: , Thread-Topic: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here Thread-Index: AQHLyGbF96/nUNcvEUKFEsEVZk1HMJP5P28Q Date: Wed, 9 Feb 2011 14:48:21 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A319399DA1@008-AM1MPN1-016.mgdnok.nokia.com> References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> <20110208215855.GC8815@srv03.cluenet.de> <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> <20110208224653.GA13986@srv03.cluenet.de> <4D52A656.3090108@viagenie.ca> In-Reply-To: <4D52A656.3090108@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Feb 2011 14:48:24.0148 (UTC) FILETIME=[67108140:01CBC868] X-Nokia-AV: Clean Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 14:48:47 -0000 I very recently tested web browsers on broken IPv6 access with: Symbian^3, = Android 2.3.1, iOS4 4.2.1, OS/X 10.6.6, Windows 7, Ubuntu 10.10 and Maemo5. None of these had happy eyeballs at least for the browsers use-case. Could you point me to this implementation so that I can give it a try as we= ll? Thanks, Teemu > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of ext Simon Perreault > Sent: 09. helmikuuta 2011 16:36 > To: v6ops@ietf.org > Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go > from here >=20 > On 2011-02-09 01:37, Roger J=F8rgensen wrote: > > I think you might overlook another _maybe_ more important point to > > consider. This might not be technical but more timedepending. > > Will Happy Eyeballs get out in time or not? >=20 > Happy eyeballs is already out. There are implementations out there that > predate the draft. The draft is actually documenting and encouraging > existing practice. >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From simon.perreault@viagenie.ca Wed Feb 9 07:02:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FE93A6A06 for ; Wed, 9 Feb 2011 07:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZsPyPywrVc0 for ; Wed, 9 Feb 2011 07:02:48 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 5A47C3A6A04 for ; Wed, 9 Feb 2011 07:02:48 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2075321BBB; Wed, 9 Feb 2011 10:02:57 -0500 (EST) Message-ID: <4D52ACA0.9050608@viagenie.ca> Date: Wed, 09 Feb 2011 10:02:56 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> <20110208215855.GC8815@srv03.cluenet.de> <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> <20110208224653.GA13986@srv03.cluenet.de> <4D52A656.3090108@viagenie.ca> <056B511A55F8AA42A3E492B7DD19A319399DA1@008-AM1MPN1-016.mgdnok.nokia.com> In-Reply-To: <056B511A55F8AA42A3E492B7DD19A319399DA1@008-AM1MPN1-016.mgdnok.nokia.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] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 15:02:49 -0000 On 2011-02-09 09:48, teemu.savolainen@nokia.com wrote: > I very recently tested web browsers on broken IPv6 access with: Symbian^3, Android 2.3.1, iOS4 4.2.1, OS/X 10.6.6, Windows 7, Ubuntu 10.10 and Maemo5. > > None of these had happy eyeballs at least for the browsers use-case. That's right. None of them do it as far as I know. > Could you point me to this implementation so that I can give it a try as well? Apple's core foundation API: http://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf http://www.ietf.org/proceedings/79/slides/nbs-8.pdf libevent also implements something very similar. Other people have mentioned Java stuff on this mailing list, but I don't know anything about that. 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 jouni.nospam@gmail.com Wed Feb 9 08:19:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29FA73A69D1 for ; Wed, 9 Feb 2011 08:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPKnpq2HjBW0 for ; Wed, 9 Feb 2011 08:19:02 -0800 (PST) Received: from vs14.mail.saunalahti.fi (vs14.mail.saunalahti.fi [195.197.172.102]) by core3.amsl.com (Postfix) with ESMTP id 036103A63EC for ; Wed, 9 Feb 2011 08:19:02 -0800 (PST) Received: from saunalahti-vams (localhost [127.0.0.1]) by vs14.mail.saunalahti.fi (Postfix) with SMTP id 6F6DCA604A; Wed, 9 Feb 2011 18:19:10 +0200 (EET) Received: from vs14.mail.saunalahti.fi ([127.0.0.1]) by vs14.mail.saunalahti.fi ([195.197.172.102]) with SMTP (gateway) id A0365C6C7F0; Wed, 09 Feb 2011 18:19:10 +0200 Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by vs14.mail.saunalahti.fi (Postfix) with ESMTP id 6295DA604A; Wed, 9 Feb 2011 18:19:10 +0200 (EET) Received: from a88-114-174-127.elisa-laajakaista.fi (a88-114-174-127.elisa-laajakaista.fi [88.114.174.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 073E51513BE; Wed, 9 Feb 2011 18:19:04 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <2B7DCEF4-2977-4087-86D3-49130A2A1DF5@apple.com> Date: Wed, 9 Feb 2011 18:19:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <59980476-D8F4-4AA0-976F-9DCECB5550DB@apple.com> <1DBC366D-F227-466D-9C07-F6B73279E6C1@gmail.com> <2B7DCEF4-2977-4087-86D3-49130A2A1DF5@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1082) X-Antivirus: VAMS Cc: draft-korhonen-v6ops-3gpp-eps.authors@tools.ietf.org, IPv6 Operations Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 16:19:03 -0000 Hi, On Feb 9, 2011, at 4:25 PM, james woodyatt wrote: > On Feb 9, 2011, at 03:04, jouni korhonen wrote: >=20 >> since 3GPP link model only supports a single prefix, having other = prefixes shorter than /64 does not make much use. >=20 > I was trying to point out that the 3GPP spec says what a UE node shall = do if the number of advertised prefixes doesn't match the link model, = but it doesn't say what to do if the advertised prefix length doesn't = match the link model. Like I said earlier.. what "any" RFC4861/2 compliant stack does when = receiving a RA with a prefix shorter than /64 and any combination of A & = L flags. A set, L [un]set -> the UE ignores the prefix (RFC4862 Section = 5.5.3 step d). A unset, L set -> the UE would fiddle its prefix list and = consume some resources until the prefix timeouts. A unset, L unset -> = The UE does nothing(?) with the prefix. If the shorter than /64 prefix = is the only advertised prefix, then the UE just gets no address. = Probably the UE would send few more RSes and the rest is up to the UE = implementation whether to keep the bearer up or close it. Of course I cannot guarantee what the legacy does. I believe there are = weird stacks out there that try to be too clever (or something) and then = manage to misbehave.. >=20 > It's an exception case, but the devil lurks in details like that. One = hopes the 3GPP people can settle it so that IETF doesn't have to do it. It's rather a broken GGSN/PGW implementation if these were to happen. - Jouni >=20 >=20 > -- > james woodyatt > member of technical staff, core os networking >=20 >=20 >=20 From jbates@brightok.net Wed Feb 9 08:19:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D633A67B2 for ; Wed, 9 Feb 2011 08:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.225 X-Spam-Level: X-Spam-Status: No, score=-3.225 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCKGYwewQ1kS for ; Wed, 9 Feb 2011 08:19:24 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 6CB203A63EC for ; Wed, 9 Feb 2011 08:19:24 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p19GJTDV020711; Wed, 9 Feb 2011 10:19:30 -0600 (CST) Message-ID: <4D52BE91.2050204@brightok.net> Date: Wed, 09 Feb 2011 10:19:29 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <990AC7E2-62A1-40A5-870E-700778743055@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops v6ops , Daniel Roesen Subject: Re: [v6ops] Disable 6to4 by default but don't deprecate Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 16:19:25 -0000 On 2/9/2011 8:18 AM, Keith Moore wrote: > Is it really reasonable to expect those users to have to know to > explicitly turn on 6to4 from here on out? > Yes. 6to4 can hurt the user's experience if they are not aware of it and the implications of using it. A knowledgeable user can activate 6to4 and has an understanding of the implications when things do not work appropriately. On the other hand, most users who understand 6to4 and require it for functionality could probably benefit even more from IRON, which may not be in the OS by default but could be setup to work in a large variety of cases for those wanting private networking, reachability, or perhaps to link to an IPv6 Internet even through LSN. In many cases, IRON appears to be like 6to4 in that a single device can act as the tunnel device to interconnect the local network to the larger network. The only questions, which I haven't looked up, is if IRON supports win32, so a traveler could hook up their laptop and connect to the IPv6 network (or the home network) via IRON and available service terminators of IRON with native IPv6 connectivity. However, in a public scenario, a mixture of IRON (from say the home) and 6to4 (from a remote location that supports it) or native, would give more options for end to end connectivity. > I think a host should be able to determine what kinds of network > access are available to it, and enable those kinds of access, without > explicit configuration by the user or administrator. I agree. Unfortunately, 6to4 connectivity detection wasn't built into 6to4. As such, it often tries to use 6to4 when there is no 6to4 availability. It should be turned off by default and perhaps an easy mechanism for enabling it (click check box). Jack (honestly, can anything more be said without rehashing a thread which I posted waaaaay too much to?) From remi.despres@free.fr Wed Feb 9 08:21:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2339F3A67B2 for ; Wed, 9 Feb 2011 08:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQ7uPAzxQJJ1 for ; Wed, 9 Feb 2011 08:21:26 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by core3.amsl.com (Postfix) with ESMTP id E8F1E3A6981 for ; Wed, 9 Feb 2011 08:21:24 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2122.sfr.fr (SMTP Server) with ESMTP id DDA7A7000091; Wed, 9 Feb 2011 17:21:33 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2122.sfr.fr (SMTP Server) with ESMTP id 5B0217000092; Wed, 9 Feb 2011 17:21:33 +0100 (CET) X-SFR-UUID: 20110209162133372.5B0217000092@msfrf2122.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 9 Feb 2011 17:21:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1FDCC67D-2D4F-4112-869C-17BBE39E7FDB@free.fr> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <990AC7E2-62A1-40A5-870E-700778743055@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: v6ops v6ops , Daniel Roesen Subject: Re: [v6ops] Disable 6to4 by default but don't deprecate Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 16:21:27 -0000 Le 9 f=E9vr. 2011 =E0 15:18, Keith Moore a =E9crit : > On Feb 9, 2011, at 9:08 AM, R=E9mi Despr=E9s wrote: >=20 >> Le 9 f=E9vr. 2011 =E0 14:32, Keith Moore a =E9crit : >>=20 >>> On Feb 9, 2011, at 4:57 AM, R=E9mi Despr=E9s wrote: >>>=20 >>>> Le 9 f=E9vr. 2011 =E0 00:34, Keith Moore a =E9crit : >>>>=20 >>>>> ... There's definitely an ideology that use of 6to4 is somehow = not legitimate and that it's therefore acceptable to sabotage it rather = than to try to fix it. >>>>=20 >>>> Would you accept a recommendation that, from now on, 6to4 should be = disabled by default. >>>=20 >>> no. I think this is very premature. >>>=20 >>> What I do accept is that if an ISP imposes NAT on its customers, = there should be some well-defined mechanism to signal that to hosts = using 6to4, so that those hosts can (a) stop trying to use 6to4 on that = link, and (b) provide a useful error message to their users. >>=20 >> You propose deployment of a new mechanism whose only purpose is to = mitigate problems that ordinary users who have 6to4 disabled don't = experience. >> This doesn't seem realistic to me. >=20 > Well, I'm hoping that ICMP is sufficient, ICMP isn't a "new mechanism", fair enough. But as we know it is unfortunately filtered in a significant part of the = real world. > and that mere configuration of existing hardware is enough to = implement the new mechanism on the provider side. Existing hardware, I suppose so, all existing software, I can't be sure. In any case still a configuration that, if not already done today, may = not be easy to obtain. >> And you ask not only to be free to enable 6to4 for your applications, = but you also insist that some other users, who don't care about these = applications, have to endure some broken connectivities. >=20 > It seems to me that you're the one asking for things to be broken. =20 Until some sort of happy eyeballs is deployed and connection that fails = is much worse, for ordinary users, than a connection in IPv4 although a = 6to4 address could have been available. For Grandma's applications, IPv4, even if across one or several NATs, = isn't that bad after all. She can wait for native IPv6 addresses to be available, and used without = her having to know it. > Given that a number of platforms have been automatically enabling 6to4 = for awhile now, to me it seems reasonable to expect that there are = applications and users that depend on this. IMHO, applications that "depend" on IPv6 should better be used in sites = that have ISP provided IPv6, or in sites operated by someone who = understands 6to4 enough to deal with its limitations. =20 > Is it really reasonable to expect those users to have to know to = explicitly turn on 6to4 from here on out? Alternatively, if they want applications that depend on IPv6, they can = switch to an ISP that offers native IPv6 addresses (be it with 6rd if = native IPv6 routing is difficult in its access network). > I think a host should be able to determine what kinds of network = access are available to it, and enable those kinds of access, without = explicit configuration by the user or administrator. Agreed, but only for network accesses that don't have intrinsic = limitations that can be detrimental to user experience. Especially if this poor experience risks to be unduly imputed to IPv6 in = general. Regards, RD From mohacsi@niif.hu Wed Feb 9 08:34:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53CFE3A65A5 for ; Wed, 9 Feb 2011 08:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.071 X-Spam-Level: X-Spam-Status: No, score=0.071 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdBKqhtaqI1Y for ; Wed, 9 Feb 2011 08:34:05 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 9C7553A67F2 for ; Wed, 9 Feb 2011 08:34:04 -0800 (PST) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id D2BB886C31; Wed, 9 Feb 2011 17:34:13 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id 6ZSkuc+b0laB; Wed, 9 Feb 2011 17:33:58 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 5DCB286C2A; Wed, 9 Feb 2011 17:33:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 51FA886C27; Wed, 9 Feb 2011 17:33:58 +0100 (CET) Date: Wed, 9 Feb 2011 17:33:58 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Simon Perreault In-Reply-To: <4D52ACA0.9050608@viagenie.ca> Message-ID: References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> <20110208215855.GC8815@srv03.cluenet.de> <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> <20110208224653.GA13986@srv03.cluenet.de> <4D52A656.3090108@viagenie.ca> <056B511A55F8AA42A3E492B7DD19A319399DA1@008-AM1MPN1-016.mgdnok.nokia.com> <4D52ACA0.9050608@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 16:34:06 -0000 On Wed, 9 Feb 2011, Simon Perreault wrote: > On 2011-02-09 09:48, teemu.savolainen@nokia.com wrote: >> I very recently tested web browsers on broken IPv6 access with: Symbian^3, Android 2.3.1, iOS4 4.2.1, OS/X 10.6.6, Windows 7, Ubuntu 10.10 and Maemo5. >> >> None of these had happy eyeballs at least for the browsers use-case. > > That's right. None of them do it as far as I know. > >> Could you point me to this implementation so that I can give it a try as well? > > Apple's core foundation API: > http://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf > http://www.ietf.org/proceedings/79/slides/nbs-8.pdf > > libevent also implements something very similar. Unfortunately libevent() evdns extension was written very badly. The IP address is represented in long int (32 bit). Best Reagrds, Janos Mohacsi From simon.perreault@viagenie.ca Wed Feb 9 08:36:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A4C3A67B3 for ; Wed, 9 Feb 2011 08:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SC+A5N3b9L4j for ; Wed, 9 Feb 2011 08:36:05 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 5EC6C3A65A5 for ; Wed, 9 Feb 2011 08:36:05 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2D14A20D21; Wed, 9 Feb 2011 11:36:14 -0500 (EST) Message-ID: <4D52C27D.1030101@viagenie.ca> Date: Wed, 09 Feb 2011 11:36:13 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mohacsi Janos References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> <20110208215855.GC8815@srv03.cluenet.de> <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> <20110208224653.GA13986@srv03.cluenet.de> <4D52A656.3090108@viagenie.ca> <056B511A55F8AA42A3E492B7DD19A319399DA1@008-AM1MPN1-016.mgdnok.nokia.com> <4D52ACA0.9050608@viagenie.ca> In-Reply-To: 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] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 16:36:06 -0000 On 2011-02-09 11:33, Mohacsi Janos wrote: > Unfortunately libevent() evdns extension was written very badly. The IP > address is represented in long int (32 bit). I believe you are talking about an old version. The newest ones do not do that. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mohacsi@niif.hu Wed Feb 9 09:15:52 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2FB3A69DD for ; Wed, 9 Feb 2011 09:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDRdkvmS7DSR for ; Wed, 9 Feb 2011 09:15:51 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 38E9A3A69D6 for ; Wed, 9 Feb 2011 09:15:51 -0800 (PST) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 8797886C02; Wed, 9 Feb 2011 18:16:00 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id SVlYlPMq96Sn; Wed, 9 Feb 2011 18:15:45 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id D841A86C1F; Wed, 9 Feb 2011 18:15:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id D554586C02; Wed, 9 Feb 2011 18:15:44 +0100 (CET) Date: Wed, 9 Feb 2011 18:15:44 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Simon Perreault In-Reply-To: <4D52C27D.1030101@viagenie.ca> Message-ID: References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> <20110208215855.GC8815@srv03.cluenet.de> <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> <20110208224653.GA13986@srv03.cluenet.de> <4D52A656.3090108@viagenie.ca> <056B511A55F8AA42A3E492B7DD19A319399DA1@008-AM1MPN1-016.mgdnok.nokia.com> <4D52ACA0.9050608@viagenie.ca> <4D52C27D.1030101@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:15:52 -0000 On Wed, 9 Feb 2011, Simon Perreault wrote: > On 2011-02-09 11:33, Mohacsi Janos wrote: >> Unfortunately libevent() evdns extension was written very badly. The IP >> address is represented in long int (32 bit). > > I believe you are talking about an old version. The newest ones do not > do that. Yes, I am talking about the stable version. You are right the new libevent2, which is currently the alpha version has ipv4 and ipv6 address resolution functions. However the int evdns_base_nameserver_add ( struct evdns_base * base, unsigned long int address ) function should be deprecated in favor of int evdns_base_nameserver_ip_add ( struct evdns_base * base, const char * ip_as_string ) Best Regards, Janos Mohacsi > > 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 joelja@bogus.com Wed Feb 9 09:29:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5E13A6981 for ; Wed, 9 Feb 2011 09:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XacQeMPGnnZQ for ; Wed, 9 Feb 2011 09:29:35 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id E6A2D3A67D1 for ; Wed, 9 Feb 2011 09:29:34 -0800 (PST) Received: from dhcp-176.nokia.net (dhcp-176.nokia.net [192.103.16.176] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p19HTY6i062200 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 9 Feb 2011 17:29:34 GMT (envelope-from joelja@bogus.com) Message-ID: <4D52CEFE.9050509@bogus.com> Date: Wed, 09 Feb 2011 09:29:34 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <990AC7E2-62A1-40A5-870E-700778743055@network-heretics.com> In-Reply-To: <990AC7E2-62A1-40A5-870E-700778743055@network-heretics.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: v6ops v6ops , Daniel Roesen Subject: Re: [v6ops] Disable 6to4 by default but don't deprecate Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:29:36 -0000 On 2/9/11 5:32 AM, Keith Moore wrote: > On Feb 9, 2011, at 4:57 AM, Rémi Després wrote: > >> Le 9 févr. 2011 à 00:34, Keith Moore a écrit : >> >>> ... There's definitely an ideology that use of 6to4 is somehow >>> not legitimate and that it's therefore acceptable to sabotage it >>> rather than to try to fix it. >> >> Would you accept a recommendation that, from now on, 6to4 should be >> disabled by default. > > no. I think this is very premature. > > What I do accept is that if an ISP imposes NAT on its customers, > there should be some well-defined mechanism to signal that to hosts > using 6to4, so that those hosts can (a) stop trying to use 6to4 on > that link, and (b) provide a useful error message to their users. No stack changes are going to percolate to a big chunk of the installed base. It would be more fruitful to consider what can be done without any additional signaling. The signal that works (for the most part, there are exceptions) is to assign an rfc 1918 scope address to the host or cpe. This is among other reasons why I thought the proposal for a new private scope address range for ISPs was a bad idea. > Keith > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From moore@network-heretics.com Wed Feb 9 10:18:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD963A6866 for ; Wed, 9 Feb 2011 10:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Tqfs0tz0-0i for ; Wed, 9 Feb 2011 10:18:41 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 71FB93A67BD for ; Wed, 9 Feb 2011 10:18:41 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PnEco-0001em-8W; Wed, 09 Feb 2011 13:18:48 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-50--1006742733 From: Keith Moore In-Reply-To: <4D52BE91.2050204@brightok.net> Date: Wed, 9 Feb 2011 13:18:40 -0500 Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <990AC7E2-62A1-40A5-870E-700778743055@network-heretics.com> <4D52BE91.2050204@br ightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940c6888384949fcb6591dfc2fc250e92a4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops v6ops , Daniel Roesen Subject: Re: [v6ops] Disable 6to4 by default but don't deprecate Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:18:43 -0000 --Apple-Mail-50--1006742733 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 9, 2011, at 11:19 AM, Jack Bates wrote: > On 2/9/2011 8:18 AM, Keith Moore wrote: >> Is it really reasonable to expect those users to have to know to >> explicitly turn on 6to4 from here on out? >>=20 >=20 > Yes. 6to4 can hurt the user's experience if they are not aware of it = and the implications of using it. A knowledgeable user can activate 6to4 = and has an understanding of the implications when things do not work = appropriately. In case it's not clear that I realize this, I do want to acknowledge = that the user's experience with 6to4 enabled can be worse than the = user's experience with 6to4 disabled. I've seen this firsthand for = years... The user's experience can also be better with 6to4, but right = now it's probably worse for most people and applications. However, I think it's dangerous to make assumptions that a user's = experience will be better in the future without 6to4. Conditions keep = changing. On one hand we expect wider adoption of IPv6 in both the = network and applications, which might favor increased use of 6to4. On = the other hand we also expect carrier-imposed NAT to start becoming more = and more common, which would contraindicate 6to4 if the host can't = recognize the condition and disable its use. =20 I also think that IETF backpedaling on 6to4 would send a confusing = message to the public and to developers, one that might impede adoption = of IPv6. I think the message we want to send is that we have IPv6 = solutions that work today, that more efficient solutions are coming, and = that the host support for both the near-term and the long-term solutions = is already widely deployed. We all know that this is a somewhat rosy = portrayal and that things could be better than they are, but we all - = operators, content providers, software developers, etc. - need to = dedicate ourselves toward making the best we can do with the solutions = that we have deployed in hosts now. =20 We have had 15+ years to tweak IPv6 and the ways to carry it. Now is = the time to make IPv6 work with the solutions that we have. That = doesn't mean we can't work on even better ways to carry IPv6 traffic, = but it does mean that we can't wait until we have better solutions in = place before we start carrying IPv6 traffic. Any means of carrying = IPv6 that's not already being shipped by OS and equipment vendors today, = is not going to be generally usable within the next several years. In that sense, 6to4 is a lot like CGN - both are ugly, both could really = use improvement, but we don't have the luxury of waiting around for = something better. (Yes, it's really unfortunate that the two conflict = with each other.) I'll believe that 6to4 is no longer needed when I can see that anybody = can get a stable connection using IPv6 space at a reasonable price. As = it happens, I was just last week shopping for internet access at my = home. Every provider that served my area was willing to give me a = static IPv4 address, or even a /29, for a small fee over the cost of = business rate IP service. I was able to find providers that could = assure me they wouldn't block IP tunneling (most didn't have a clue as = to what I was talking about). But not a single one of those providers = could offer me any kind of IPv6 service. I'd even settle for a = configured tunnel as long as it terminated somewhere nearby. Not = available. I think ISPs need to realize that 6to4 is a well-established standard = for transmitting v6 over the public v4 Internet, it's widely supported = in hosts, it is going to be used, and the network needs to support it = too. For networks that can't support use of 6to4 addresses by their = customers (e.g. because of CGN), the best solution - really the only = viable solution that I can see - is for them to offer native IPv6 - = ideally, in a way that doesn't require the customer to do anything = different. And even those networks may need to provide and maintain = 6to4 relay routers so that their customers using native v6 can reliably = talk to hosts with 6to4 addresses. Back to the question of whether hosts should enable 6to4 by default. = I'm very leery of expecting users to know what 6to4 means and whether to = enable it. I'm also very leery of expecting users to deal with = arbitrary changes in the way their platforms deal with the network. I = think it's incumbent on the CGN people to define a simple and standard = way to signal to hosts that 6to4 can't possibly work for them. And if = IETF's going to recommend a change to host behavior, it should be to = support that means of signaling, rather than to tell them to disable = 6to4 by default. Having said that, it seems that OS vendors are always tweaking their = autoconfiguration code anyway. I think they're probably in a better = position to know what works for their customers than IETF is. As for the other problems with 6to4 that Brian identified, these are = problems in the network, and it's the network's job to address them. = Regardless of what we decide here, 6to4 is not going away until native = v6 becomes ubiquitous. Keith --Apple-Mail-50--1006742733 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 2/9/2011 8:18 AM, = Keith Moore wrote:
Is it really reasonable = to expect those users to have to know to
explicitly turn on 6to4 from here on = out?


Yes. = 6to4 can hurt the user's experience if they are not aware of it and the = implications of using it. A knowledgeable user can activate 6to4 and has = an understanding of the implications when things do not work = appropriately.

In case it's not = clear that I realize this, I do want to acknowledge that the user's = experience with 6to4 enabled can be worse than the user's experience = with 6to4 disabled.  I've seen this firsthand for years... =  The user's experience can also be better with 6to4, but right now = it's probably worse for most people and = applications.

However, I think it's dangerous = to make assumptions that a user's experience will be better in = the future without 6to4.   Conditions keep changing.  On one = hand we expect wider adoption of IPv6 in both the network and = applications, which might favor increased use of 6to4.   On the = other hand we also expect carrier-imposed NAT to start becoming more and = more common, which would contraindicate 6to4 if the host can't recognize = the condition and disable its use.  

I = also think that IETF backpedaling on 6to4 would send a confusing message = to the public and to developers, one that might impede adoption of IPv6. =  I think the message we want to send is that we have IPv6 solutions = that work today, that more efficient solutions are coming, and that the = host support for both the near-term and the long-term solutions is = already widely deployed.  We all know that this is a somewhat rosy = portrayal and that things could be better than they are, but we = all - operators, content providers, software developers, etc. - = need to dedicate ourselves toward making the best we can do with the = solutions that we have deployed in hosts now.   =  

We have had 15+ years to tweak IPv6 and = the ways to carry it.   Now is the time to make IPv6 work with the = solutions that we have.  That doesn't mean we can't work on even = better ways to carry IPv6 traffic, but it does mean that we can't wait = until we have better solutions in place before we start carrying IPv6 = traffic.   Any means of carrying IPv6 that's not already being = shipped by OS and equipment vendors today, is not going to be generally = usable within the next several years.

In that = sense, 6to4 is a lot like CGN - both are ugly, both could really use = improvement, but we don't have the luxury of waiting around for = something better.  (Yes, it's really unfortunate that the two = conflict with each other.)

I'll believe that = 6to4 is no longer needed when I can see that anybody can get a stable = connection using IPv6 space at a reasonable price.  As it happens, = I was just last week shopping for internet access at my home. =  Every provider that served my area was willing to give me a static = IPv4 address, or even a /29, for a small fee over the cost of business = rate IP service.   I was able to find providers that could assure = me they wouldn't block IP tunneling (most didn't have a clue as to what = I was talking about).  But not a single one of those providers = could offer me any kind of IPv6 service.   I'd even settle for a = configured tunnel as long as it terminated somewhere nearby.  Not = available.

I think ISPs need to realize that = 6to4 is a well-established standard for transmitting v6 over the public = v4 Internet, it's widely supported in hosts, it is going to be used, and = the network needs to support it too.  For networks that can't = support use of 6to4 addresses by their customers (e.g. because of CGN), = the best solution - really the only viable solution that I can see - is = for them to offer native IPv6 - ideally, in a way that doesn't require = the customer to do anything different.   And even those networks = may need to provide and maintain 6to4 relay routers so that their = customers using native v6 can reliably talk to hosts with 6to4 = addresses.

Back to the question of whether = hosts should enable 6to4 by default.  I'm very leery of expecting = users to know what 6to4 means and whether to enable it.  I'm also = very leery of expecting users to deal with arbitrary changes in the way = their platforms deal with the network.    I think it's = incumbent on the CGN people to define a simple and standard way to = signal to hosts that 6to4 can't possibly work for them.  And if = IETF's going to recommend a change to host behavior, it should be to = support that means of signaling, rather than to tell them to disable = 6to4 by default.

Having said that, it seems = that OS vendors are always tweaking their autoconfiguration code anyway. =  I think they're probably in a better position to know what works = for their customers than IETF is.

As for the = other problems with 6to4 that Brian identified, these are problems in = the network, and it's the network's job to address them.   = Regardless of what we decide here, 6to4 is not going away until native = v6 becomes = ubiquitous.

Keith

= --Apple-Mail-50--1006742733-- From joelja@bogus.com Wed Feb 9 10:37:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210CB3A67AB for ; Wed, 9 Feb 2011 10:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h76pcgc451VM for ; Wed, 9 Feb 2011 10:37:14 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 06C243A672F for ; Wed, 9 Feb 2011 10:37:13 -0800 (PST) Received: from dhcp-176.nokia.net (dhcp-176.nokia.net [192.103.16.176] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p19IbHXw066122 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 9 Feb 2011 18:37:18 GMT (envelope-from joelja@bogus.com) Message-ID: <4D52DEDD.8060903@bogus.com> Date: Wed, 09 Feb 2011 10:37:17 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Pekka Savola References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Daniel Roesen , Keith Moore Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:37:15 -0000 On 2/9/11 5:51 AM, Pekka Savola wrote: > On Wed, 9 Feb 2011, Keith Moore wrote: > I agree it's unfortunate that 6to4 would get turned off, but 6to4 > implementations will get disabled with private IPv4 addresses. 3056 is pretty unequivocal as to what to do with a private ip address... there are exceptions in that a few of which lorenzo found will use them anyway. > This is > MUCH better than IPv6 blackholing when 6to4 is enabled on end-systems > but blocked in the network. Systems that end up behind LSN and private > addresses also have the option of starting to use Teredo or another > transition mechanism that can punch through LSN. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From moore@network-heretics.com Wed Feb 9 10:40:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05593A6768 for ; Wed, 9 Feb 2011 10:40:41 -0800 (PST) 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.071, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQYNzWO4RRes for ; Wed, 9 Feb 2011 10:40:41 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id DA4553A672F for ; Wed, 9 Feb 2011 10:40:40 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PnEy9-0004p4-Il; Wed, 09 Feb 2011 13:40:50 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: <1FDCC67D-2D4F-4112-869C-17BBE39E7FDB@free.fr> Date: Wed, 9 Feb 2011 13:40:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <990AC7E2-62A1-40A5-870E-700778743055@network-heretics.com> <1FDCC67D-2D4F-4112- 869C-17BBE39E7FDB@free.fr> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da94051d1f99d138855e27fd5bf94d21a6510350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops v6ops , Daniel Roesen Subject: Re: [v6ops] Disable 6to4 by default but don't deprecate Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:40:42 -0000 On Feb 9, 2011, at 11:21 AM, R=E9mi Despr=E9s wrote: >>>>=20 >>>> What I do accept is that if an ISP imposes NAT on its customers, = there should be some well-defined mechanism to signal that to hosts = using 6to4, so that those hosts can (a) stop trying to use 6to4 on that = link, and (b) provide a useful error message to their users. >>>=20 >>> You propose deployment of a new mechanism whose only purpose is to = mitigate problems that ordinary users who have 6to4 disabled don't = experience. >>> This doesn't seem realistic to me. >>=20 >> Well, I'm hoping that ICMP is sufficient, >=20 > ICMP isn't a "new mechanism", fair enough. > But as we know it is unfortunately filtered in a significant part of = the real world. Presumably the networks that implement CGN are in a position to arrange = that ICMP not be filtered between their routers and their customers, = which is all that matters for this case. >> It seems to me that you're the one asking for things to be broken. =20= >=20 > Until some sort of happy eyeballs is deployed and connection that = fails is much worse, for ordinary users, than a connection in IPv4 = although a 6to4 address could have been available. I understand that native v6 doesn't work very well right now either. = The solution in both cases - 6to4 and native v6 - is for the network = operators to work out the kinks. Of course, the sooner they work out = the kinks with native v6, the fewer problems they'll see with 6to4. (Happy eyeballs, BTW, is nothing new. I was researching and = implementing similar things, and pointing out that address selection = rules could never work well, at least as far back as 2005. The = reactions I got from both IETF people and funding agencies at the time = ranged from indifference to hostility. So I'm glad to see that these = issues are finally getting the attention they deserve.) > For Grandma's applications, IPv4, even if across one or several NATs, = isn't that bad after all. > She can wait for native IPv6 addresses to be available, and used = without her having to know it. I totally do not believe analyses that only consider the case of the = hypothetical Grandma. The Internet and the needs of its users are much = more diverse than Grandma. >> Given that a number of platforms have been automatically enabling = 6to4 for awhile now, to me it seems reasonable to expect that there are = applications and users that depend on this. >=20 > IMHO, applications that "depend" on IPv6 should better be used in = sites that have ISP provided IPv6, or in sites operated by someone who = understands 6to4 enough to deal with its limitations. You can believe that if you want, but the very purpose of 6to4 was to = enable v6 without ISPs having to explicitly provide for it. I suppose = the irony there is that because of the potential for flaky relay = routers, ISPs have to deal with it anyway. If 6to4 has provided them = extra incentive to get native v6 working, so much the better (not that I = don't think anyone seriously is trying to avoid that any more, but it = was a problem until recently). >> Is it really reasonable to expect those users to have to know to = explicitly turn on 6to4 from here on out? >=20 > Alternatively, if they want applications that depend on IPv6, they can = switch to an ISP that offers native IPv6 addresses (be it with 6rd if = native IPv6 routing is difficult in its access network). Those ISPs appear to be quite rare at present. =20 >> I think a host should be able to determine what kinds of network = access are available to it, and enable those kinds of access, without = explicit configuration by the user or administrator. >=20 > Agreed, but only for network accesses that don't have intrinsic = limitations that can be detrimental to user experience. Then they definitely shouldn't enable NATted IPv4 by default. =20 Keith From moore@network-heretics.com Wed Feb 9 10:45:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3B5E3A672F for ; Wed, 9 Feb 2011 10:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QMsQvrUQDVo for ; Wed, 9 Feb 2011 10:45:06 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 7E7903A69E0 for ; Wed, 9 Feb 2011 10:45:05 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PnF2O-0001JM-Ro; Wed, 09 Feb 2011 13:45:13 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D52CEFE.9050509@bogus.com> Date: Wed, 9 Feb 2011 13:45:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <990AC7E2-62A1-40A5-870E-700778743055@network-heretics.com> <4D52CEFE.9050509@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9409eb19c612ff392790b07880f883e75f3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops v6ops , Daniel Roesen Subject: Re: [v6ops] Disable 6to4 by default but don't deprecate Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:45:06 -0000 On Feb 9, 2011, at 12:29 PM, Joel Jaeggli wrote: >> What I do accept is that if an ISP imposes NAT on its customers, >> there should be some well-defined mechanism to signal that to hosts >> using 6to4, so that those hosts can (a) stop trying to use 6to4 on >> that link, and (b) provide a useful error message to their users. >=20 > No stack changes are going to percolate to a big chunk of the = installed > base. It would be more fruitful to consider what can be done without = any > additional signaling. Is it really significantly easier to get a change to default = configuration than a change to the stack code? Seems to me like about = the same amount of coding, documentation, and QA in both cases. If = anything, the change for configuration seems a bit worse because it more = directly affects the user experience. > The signal that works (for the most part, there are exceptions) is to > assign an rfc 1918 scope address to the host or cpe. This is among = other > reasons why I thought the proposal for a new private scope address = range > for ISPs was a bad idea. If ISPs that use NAT can make this work for them and their customers, = I'm certainly happy that it happens to disable 6to4. But I understand = if ISPs find that on balance using RFC 1918 addresses causes more = problems than it solves. Keith =20= From dr@cluenet.de Wed Feb 9 10:50:18 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23AC03A69E6 for ; Wed, 9 Feb 2011 10:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzalOJ-m6SUk for ; Wed, 9 Feb 2011 10:50:17 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id F2A803A69E7 for ; Wed, 9 Feb 2011 10:50:16 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 7FB451080AC; Wed, 9 Feb 2011 19:50:25 +0100 (CET) Date: Wed, 9 Feb 2011 19:50:25 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110209185025.GA22226@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <4D52DEDD.8060903@bogus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D52DEDD.8060903@bogus.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:50:18 -0000 On Wed, Feb 09, 2011 at 10:37:17AM -0800, Joel Jaeggli wrote: > On 2/9/11 5:51 AM, Pekka Savola wrote: > > I agree it's unfortunate that 6to4 would get turned off, but 6to4 > > implementations will get disabled with private IPv4 addresses. > > 3056 is pretty unequivocal as to what to do with a private ip address... > there are exceptions in that a few of which lorenzo found will use them > anyway. Is there any quantification of "a few"? I was under the impression that "a few" are actually "quite many". Unfortunately I have no sources to cite, but that's indeed a good item to check in CPE testing for. I've just checked CentOS 5 - the IPv6 init scripts take care that 6to4 ain't enabled when the "outside" interface doesn't have a global IP. Given that it's an init script thing and not a kernel thing, I fear that CPE router vendors using Linux are not necessarily as attentive. Perhaps the problem is really only a real problem when non-RFC1918 is being used for the WAN interface. Customer end hosts don't make me worry - CPE routers implementing 6to4 do. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From Fred.L.Templin@boeing.com Wed Feb 9 11:04:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA023A67FD for ; Wed, 9 Feb 2011 11:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.406 X-Spam-Level: X-Spam-Status: No, score=-6.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDe3WE7dtD-V for ; Wed, 9 Feb 2011 11:04:32 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id AB1A23A672F for ; Wed, 9 Feb 2011 11:04:32 -0800 (PST) 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 p19J4exC014057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 9 Feb 2011 13:04:40 -0600 (CST) 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 p19J4edp005859 for ; Wed, 9 Feb 2011 13:04:40 -0600 (CST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p19J4dQ8005841 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Wed, 9 Feb 2011 13:04:39 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Wed, 9 Feb 2011 11:04:39 -0800 From: "Templin, Fred L" To: v6ops v6ops Date: Wed, 9 Feb 2011 11:04:38 -0800 Thread-Topic: IRON bibliography Thread-Index: AcvIibvHcd6eNVLbS7atTmZ9CWLhPwAABanA Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <2011020717562 4.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-her etics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net > <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.500 0404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.c om> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB 54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAW M12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics. com> <990AC7E2-62A1-40A5-870E -700778743055@network-heretics.com><4D52CEFE.9050509@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: [v6ops] IRON bibliography X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:04:33 -0000 Hi, There seems to be sufficient interest in IRON that I thought it might be helpful to post a bibliography in one place rather than expect folks to glean all of the pieces that are scattered throughout the list archives. IRON itself is actually a conglomerate of architectural constructs and functional specifications that also includes RANGER, VET and SEAL. The big-picture can be understood by just looking at the IRON core document: http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt but if you want to dig deeper the full set of constituent documents are here: http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt http://www.rfc-editor.org/rfc/rfc5720.txt http://tools.ietf.org/html/draft-templin-intarea-vet http://tools.ietf.org/html/draft-templin-intarea-seal And, if you get that far you might also want to take a look at the related use case analysis documents, which includes operational considerations of interest not only to ISPs but also to any other prospective IPv6 domains of applicability: http://www.rfc-editor.org/internet-drafts/draft-russert-rangers-05.txt http://tools.ietf.org/html/draft-templin-iron-pm-00.html http://tools.ietf.org/html/draft-templin-ironmike-00=20 Finally, a first-version implementation is available here: http://isatap.com/iron/iron-1.3.tgz I am working on an updated version of the implementation and hope to release that within the next several days. As always, I am open to your comments and questions. Thanks - Fred fred.l.templin@boeing.com= From dr@cluenet.de Wed Feb 9 11:06:37 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 570593A67FD for ; Wed, 9 Feb 2011 11:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrG6WCrQbIzc for ; Wed, 9 Feb 2011 11:06:36 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 3C4EA3A672F for ; Wed, 9 Feb 2011 11:06:36 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id ED77F10807E; Wed, 9 Feb 2011 20:06:45 +0100 (CET) Date: Wed, 9 Feb 2011 20:06:45 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110209190645.GB22226@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:06:37 -0000 On Wed, Feb 09, 2011 at 08:39:39AM -0500, Keith Moore wrote: > It seems to me that if an ISP starts giving RFC 1918 addresses to its > customers, that's going to cause breakage too. Indeed. Pick your poison. There are a variety of reasons why operators might reallyreally want/need to avoid assigning RFC1918 addresses to untrusted customer devices [hint embedded]. Some operators are trying to avoid NAT444 altogether because of all the landmines associated with it (read: e.g. DS-Lite - which will deliver native IPv6 proper as a "side product" as well). > And while I agree that the two cases are distinct, using any kind of > NAT breaks 6to4. And if that's the only means of v6 access available > to the customer, the effect of LSN _is_ to break IPv6. Looking from flight level 850, most couldn't care less, as long it doesn't lead to blackholing and thus longish timeouts on application level => impaired IPv4 Internet experience. As long as there is no (relevant!) IPv6-only content, delivering IPv6 to eyeballs is not a matter of immediate(!) business continuity. So while it might be that a few techies don't get their funky 6to4 anymore to watch the dancing turtle, it doesn't really matter as long as we saved the "Internet experience" for the other 99,999*% paying customers not even able to spell Aiy Pee Wii Sixxx. I fully encourage all our competitors to introduce LSN and _not_ work on urgent native IPv6 access deployment as well :-) Best regards, Daniel (now going to search for the soap bar to wash his mouth) -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From dr@cluenet.de Wed Feb 9 11:10:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D113A67AE for ; Wed, 9 Feb 2011 11:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEW8XX7mr90X for ; Wed, 9 Feb 2011 11:10:42 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id D6AC43A6821 for ; Wed, 9 Feb 2011 11:10:41 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 9BFD8108089; Wed, 9 Feb 2011 20:10:51 +0100 (CET) Date: Wed, 9 Feb 2011 20:10:51 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110209191051.GC22226@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:10:42 -0000 On Wed, Feb 09, 2011 at 01:17:31PM +0200, Pekka Savola wrote: > That will certainly happen if the ISP is natting between two public address > spaces. But I don't think LSN would do that by definition? What's the definition of "LSN"? In my book it means: - NAT device - supporting lotsa sessions and Gigabits - operated by the ISP (that's already a stretch) No less, and certainly no more. > If the ISP switches the user to use a private IP space, 6to4 usage will > just stop but it won't break. In an ideal world, it would. > Let's keep these two cases clearly distinct. While it's indeed a good idea to make that clear distinction, in the net effect it's about quantity. Folks doing NAT444 with privat IPs on CPE WAN side will see far less 6to4 problems than ISPs doing NAT444 with global IPs on CPE WAN side, granted. But still both have the same problem as not all implementation "behave". Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From suresh.krishnan@ericsson.com Wed Feb 9 11:10:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184A43A69DD for ; Wed, 9 Feb 2011 11:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.099 X-Spam-Level: X-Spam-Status: No, score=-100.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbgNepM2LAL4 for ; Wed, 9 Feb 2011 11:10:46 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 2DE303A69D3 for ; Wed, 9 Feb 2011 11:10:46 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p19JspbY013211; Wed, 9 Feb 2011 13:54:53 -0600 Received: from [142.133.10.107] (147.117.20.213) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.2.234.1; Wed, 9 Feb 2011 14:10:51 -0500 Message-ID: <4D52E691.4090505@ericsson.com> Date: Wed, 9 Feb 2011 14:10:09 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: james woodyatt References: <59980476-D8F4-4AA0-976F-9DCECB5550DB@apple.com> In-Reply-To: <59980476-D8F4-4AA0-976F-9DCECB5550DB@apple.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-korhonen-v6ops-3gpp-eps.authors@tools.ietf.org" , IPv6 Operations Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:10:50 -0000 Hi James, On 11-02-08 09:43 PM, james woodyatt wrote: > On Feb 8, 2011, at 15:58, james woodyatt wrote: >> Okay. Does that mean that the IID signaled in the PDN connection setup is *NOT eligible for use with the RFC 4429 optimistic DAD algorithm? Why wouldn't it be? If that's the case, then surely the draft should be amended to explain that! > > Ah. I see my goof. The draft says this: > >> The details of the 3GPP link-model and address configuration is described in Section 11.2.1.3.2a of [3GPP.29.061]. > > That document elaborates: > >> Since the GGSN guarantees that the Prefix is unique, the MS does not need to perform any Duplicate Address Detection on addresses it creates. That is, the 'DupAddrDetectTransmits' variable in the MS should have a value of zero. If the MS finds more than one Prefix in the Router Advertisement message, it shall only consider the first one and silently discard the others. The GGSN shall not generate any globally unique IPv6 addresses for itself using the Prefix assigned to the MS in the Router Advertisement. > > It seems to me like this draft would be improved by spelling that out explicitly here too. > > On a related note, I didn't find any specific language in the 3GPP draft explaining what to do when the PIO option in the RA message contains a prefix length shorter than 64 bits. Seems like an oversight. One assumes that zero-extending to 64 bits is acceptable, but a normative instruction would be better. What you are pointing out is right, but it is a generic deficiency of RFC4862 that states "If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored." You suggestion of zero extending the prefix to a /64 makes sense, but it is probably a configuration error to be advertising a shorter than /64 prefix in an RA. Thanks Suresh From cb.list6@gmail.com Wed Feb 9 11:28:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143793A69C5 for ; Wed, 9 Feb 2011 11:28:59 -0800 (PST) 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=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sC3U9Jm+g+h3 for ; Wed, 9 Feb 2011 11:28:58 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 1A4E93A6816 for ; Wed, 9 Feb 2011 11:28:58 -0800 (PST) Received: by qwi2 with SMTP id 2so442738qwi.31 for ; Wed, 09 Feb 2011 11:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=bsl8Vns3nPQzwFARr+FVIAmyRe6PKSkXp6FzAMHojb8=; b=mYnDUrbL8lMxeIFbTq3cjQhro/II6aliqgVbjbRjL6SmjOdKTCtHEx6wDxxo2KsWBY cAXl3carRY1Kuxy5Vo/swoCiQLxLhe94WTxGsQeGMLsyaUnUifdtJxiO1J1mY/yKJU0w vBFBCprWHU1DCdlJEpAelFiAXGU2yyeuGoKY0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=iTs56cQda7H02qLydq845GktfQbr3NujL31kiQ5MFGclT5000wBI8SKTjsw9u79SHn MZamivdyBTp3A21X6FhfcFcj9azqFV1LRxyHA8uWxRWbOg3ruUM06RXWEMwEbpNwnRpR w5RK/VVwzO7aBcxiroK8MirDICD8hWTqyF4Rc= MIME-Version: 1.0 Received: by 10.229.96.83 with SMTP id g19mr15160788qcn.106.1297279745395; Wed, 09 Feb 2011 11:29:05 -0800 (PST) Received: by 10.229.224.79 with HTTP; Wed, 9 Feb 2011 11:29:05 -0800 (PST) In-Reply-To: <20110209185025.GA22226@srv03.cluenet.de> References: <4D52DEDD.8060903@bogus.com> <20110209185025.GA22226@srv03.cluenet.de> Date: Wed, 9 Feb 2011 11:29:05 -0800 Message-ID: From: Cameron Byrne To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:28:59 -0000 On Wed, Feb 9, 2011 at 10:50 AM, Daniel Roesen wrote: > On Wed, Feb 09, 2011 at 10:37:17AM -0800, Joel Jaeggli wrote: >> On 2/9/11 5:51 AM, Pekka Savola wrote: >> > I agree it's unfortunate that 6to4 would get turned off, but 6to4 >> > implementations will get disabled with private IPv4 addresses. >> >> 3056 is pretty unequivocal as to what to do with a private ip address... >> there are exceptions in that a few of which lorenzo found will use them >> anyway. > > Is there any quantification of "a few"? I was under the impression that > "a few" are actually "quite many". Unfortunately I have no sources to > cite, but that's indeed a good item to check in CPE testing for. > > I've just checked CentOS 5 - the IPv6 init scripts take care that 6to4 > ain't enabled when the "outside" interface doesn't have a global IP. > Given that it's an init script thing and not a kernel thing, I fear that > CPE router vendors using Linux are not necessarily as attentive. > > Perhaps the problem is really only a real problem when non-RFC1918 is > being used for the WAN interface. > > Customer end hosts don't make me worry - CPE routers implementing 6to4 > do. So i just did some quick testing of my own on my network, LSN + BOGON. I did not see any breakage with dual-stack web sites. So what really breaks to the customer . Setup: Current Windows 7 Netbook from Dell Current browsers Opera (11.01), Firefox (3.6.11), IE (8.0.76), and Chrome (9.0.597) nslookup result in both A and AAAA records for dual-stack domains BOGON IPv4 address on PC via 3G Null route of 6to4 anycast in network 6to4 address shows up in "ipconfig" No special changes to the OS or host config, this system generally works fine and is "normal" Results: All websites loaded without any noticeable delay Chrome: www.ucla.edu, www.arin.net IE: www.he.net, www.brocade.com Opera: www.ietf.org, www.sixy.ch Firefox: www.ripe.net, ip6.me, www.comcast6.net So, where do we find the bad user experience in this to joe sixpack that does not care or know about IPv6? How does this impact world ipv6 day? Thanks, Cameron From dr@cluenet.de Wed Feb 9 11:46:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7276C3A69C2 for ; Wed, 9 Feb 2011 11:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMw1wUMBftNE for ; Wed, 9 Feb 2011 11:46:38 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id A75633A6901 for ; Wed, 9 Feb 2011 11:46:38 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 736781080A0; Wed, 9 Feb 2011 20:46:48 +0100 (CET) Date: Wed, 9 Feb 2011 20:46:48 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110209194648.GA27666@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <4D52DEDD.8060903@bogus.com> <20110209185025.GA22226@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:46:39 -0000 On Wed, Feb 09, 2011 at 11:29:05AM -0800, Cameron Byrne wrote: > BOGON IPv4 address on PC via 3G What is a "BOGON" address in that specific case? RFC1918? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From cb.list6@gmail.com Wed Feb 9 13:26:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3F453A69F6 for ; Wed, 9 Feb 2011 13:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.215 X-Spam-Level: X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PP5ItQ79-f1E for ; Wed, 9 Feb 2011 13:26:24 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id DBC033A6925 for ; Wed, 9 Feb 2011 13:26:23 -0800 (PST) Received: by qyj19 with SMTP id 19so505209qyj.10 for ; Wed, 09 Feb 2011 13:26:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=EGYVhnXIZFjUVXMlwhJzcpWTFo/YCqG9/K7SJpIBN/U=; b=IYdPQLv6o1oyVzoz7Gyi77eyvpwlW7sUnF3QGy03ket2/3Iadj0APwRSOwGLsq5ZxC rX0vMXxrlQsFT7NOu0BxeyCNwLLmJ70lWGJSt44fmvagzSc/XWa9LKH8+ge0Ftjk6lQq UVRoZYL70rPvC+CqTKi+vUO00PR+pequ7Saak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=J631fSJThO8p05qDJrEs8n3ZyGSp8JDH3LhGbSN5FNIj3ksmqUlh/AYVkBZxbMIU/+ OM6PS/z8aR8pgxSop6midLiPFPyI9R4LvcJdVe+dGIuBhPZnxVOLNPwbQFJluvMdDRrs VyHDsfMls8x2cmPmhWXloxilOyBZA7Q5WPMgo= MIME-Version: 1.0 Received: by 10.229.87.149 with SMTP id w21mr13518287qcl.68.1297286793893; Wed, 09 Feb 2011 13:26:33 -0800 (PST) Received: by 10.229.224.79 with HTTP; Wed, 9 Feb 2011 13:26:33 -0800 (PST) Received: by 10.229.224.79 with HTTP; Wed, 9 Feb 2011 13:26:33 -0800 (PST) In-Reply-To: <20110209194648.GA27666@srv03.cluenet.de> References: <4D52DEDD.8060903@bogus.com> <20110209185025.GA22226@srv03.cluenet.de> <20110209194648.GA27666@srv03.cluenet.de> Date: Wed, 9 Feb 2011 13:26:33 -0800 Message-ID: From: Cameron Byrne To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=0016364ee3fc859690049be01ef1 Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:26:24 -0000 --0016364ee3fc859690049be01ef1 Content-Type: text/plain; charset=ISO-8859-1 On Feb 9, 2011 11:46 AM, "Daniel Roesen" wrote: > > On Wed, Feb 09, 2011 at 11:29:05AM -0800, Cameron Byrne wrote: > > BOGON IPv4 address on PC via 3G > > What is a "BOGON" address in that specific case? RFC1918? > UK military range > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --0016364ee3fc859690049be01ef1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Feb 9, 2011 11:46 AM, "Daniel Roesen" <dr@cluenet.de> wrote:
>
> On Wed, Feb 09, 2011 at 11:29:05AM -0800, Cameron Byrne wrote:
> > BOGON IPv4 address on PC via 3G
>
> What is a "BOGON" address in that specific case? RFC1918? >

UK military=A0 range

> Best regards,
> Daniel
>
> --
> CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--0016364ee3fc859690049be01ef1-- From brian.e.carpenter@gmail.com Wed Feb 9 13:29:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F368B3A69FF for ; Wed, 9 Feb 2011 13:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.59 X-Spam-Level: X-Spam-Status: No, score=-103.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmUpmVJn06Eg for ; Wed, 9 Feb 2011 13:29:30 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id E47B83A6823 for ; Wed, 9 Feb 2011 13:29:29 -0800 (PST) Received: by wyf23 with SMTP id 23so696503wyf.31 for ; Wed, 09 Feb 2011 13:29:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=efsm1qFQ4QJ0/at9wKgMiShP8xGTXNooP6vvWezePsw=; b=HDaHBs7JesqJeSbUV4YZ3KwbQm22BZPJDENUoCRXiYvoMuk0KrIw64Mwzub3V0XyG/ GzFOxNdD7icJ3kMv1vMki3SlqVQxhl1cARHHnZvpSXMOlue1XMOxSo70c+uq88eIY9wM uC5xQNOdwGOMAHARjHdNftaQThRZ3BUaLZUWw= 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=XSlQ34lkKYtff4yDPUGgYwLIFy5FH59YUg82diEEUDVD6pAekqCqFbNEC6D7IQhEo7 9Lh5E3KncFYrW2mt0sOloxZHDJVBaTT0gG/9KbMyDht/LSzAE/H323mevCXITHDgBf1/ Qfd72NrGSc9X908H4rK7hkzNMAXYF9NGSBuX8= Received: by 10.227.136.79 with SMTP id q15mr5810885wbt.146.1297286963460; Wed, 09 Feb 2011 13:29:23 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id s50sm429499weh.22.2011.02.09.13.29.19 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 13:29:21 -0800 (PST) Message-ID: <4D53072C.4000108@gmail.com> Date: Thu, 10 Feb 2011 10:29:16 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault References: <8B0FBDF0-C63A-4D51-B94E-1C2E0FDC4E19@nominum.com> <4D5154E1.60000@brightok.net> <60141F20-3E0E-444F-93B7-65039BEA8F42@cisco.com> <20110208215855.GC8815@srv03.cluenet.de> <84C8D5CA-65D3-4A59-ABF1-23864DD37368@cisco.com> <20110208224653.GA13986@srv03.cluenet.de> <4D52A656.3090108@viagenie.ca> <056B511A55F8AA42A3E492B7DD19A319399DA1@008-AM1MPN1-016.mgdnok.nokia.com> <4D52ACA0.9050608@viagenie.ca> In-Reply-To: <4D52ACA0.9050608@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:29:34 -0000 On 2011-02-10 04:02, Simon Perreault wrote: .. > Other people have mentioned Java stuff on this mailing list, but I don't > know anything about that. Java doesn't really do this; what it does (afaik) is hide the address family from the application programmer, who only uses the FQDN. But it doesn't do all the happiness stuff. Actually if the Java runtime could do so, it would be a great leap forward IMHO. Brian From brian.e.carpenter@gmail.com Wed Feb 9 13:39:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDDF63A67C1 for ; Wed, 9 Feb 2011 13:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.591 X-Spam-Level: X-Spam-Status: No, score=-103.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T7LasDP+aDg for ; Wed, 9 Feb 2011 13:39:09 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C942C3A6823 for ; Wed, 9 Feb 2011 13:39:08 -0800 (PST) Received: by wwa36 with SMTP id 36so681939wwa.13 for ; Wed, 09 Feb 2011 13:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qyqwMjzQvVeqkosroiHZLTzexa7RQO1d2ISJ+o3SA/Q=; b=QXr1L3KuYawJnBC1ye5y68AfOAkfMeg6nPfYoLuhLPd7UlrHjabZrz8fux/hIJm+oX uuV2VPcSzUQknbifqMgNveMnrJSxEv7VY5SwUEKFX7HcSMNHmb1hpQu6TlxpBFhUJHYq vy5tAcqz6Ml7v8RETgvVDghieEyyelTqUONpM= 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=hZfTk0m9Afv1AVMrdlUTsxtgSF41VWVGyrpkevoTh0gD9GTGCmITQVKc+0NPLXWPnL zu1npSKQvTR7aNlzLaFg2kh+UUa5zQFxuui+kVCOnBwOO7H7pIWRdgTaJIODj87bDHrp 2KV+oIDi2jX8eBOYNQNYkPFO8w+iqLRnwmjbI= Received: by 10.227.135.4 with SMTP id l4mr3828595wbt.95.1297287558561; Wed, 09 Feb 2011 13:39:18 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id r80sm434297wei.15.2011.02.09.13.39.15 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 13:39:17 -0800 (PST) Message-ID: <4D530981.7060201@gmail.com> Date: Thu, 10 Feb 2011 10:39:13 +1300 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: <4D52DEDD.8060903@bogus.com> <20110209185025.GA22226@srv03.cluenet.de> <20110209194648.GA27666@srv03.cluenet.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:39:09 -0000 On 2011-02-10 10:26, Cameron Byrne wrote: > On Feb 9, 2011 11:46 AM, "Daniel Roesen" wrote: >> On Wed, Feb 09, 2011 at 11:29:05AM -0800, Cameron Byrne wrote: >>> BOGON IPv4 address on PC via 3G >> What is a "BOGON" address in that specific case? RFC1918? >> > > UK military range As far as 6to4 is concerned, any non-RFC1918 address that in reality is not connected directly to the global Internet is a bogon. It really doesn't matter where the ISP has "borrowed" it from. And before anyone asks, we can't solve this with a globally defined blacklist to be added to RFC 1918, because any ISP operating a CGN can "borrow" any address range they decide to. Brian From jbates@brightok.net Wed Feb 9 13:44:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD593A6A00 for ; Wed, 9 Feb 2011 13:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.225 X-Spam-Level: X-Spam-Status: No, score=-3.225 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG6DPZu2Fsfl for ; Wed, 9 Feb 2011 13:44:38 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id CB66A3A6823 for ; Wed, 9 Feb 2011 13:44:38 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p19Lim5q024809; Wed, 9 Feb 2011 15:44:48 -0600 (CST) Message-ID: <4D530AD0.6060103@brightok.net> Date: Wed, 09 Feb 2011 15:44:48 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian E Carpenter References: <4D52DEDD.8060903@bogus.com> <20110209185025.GA22226@srv03.cluenet.de> <20110209194648.GA27666@srv03.cluenet.de> <4D530981.7060201@gmail.com> In-Reply-To: <4D530981.7060201@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:44:39 -0000 On 2/9/2011 3:39 PM, Brian E Carpenter wrote: > And before anyone asks, we can't solve this with a globally > defined blacklist to be added to RFC 1918, because any ISP > operating a CGN can "borrow" any address range they decide to. > Or just mirror their own allocated space 100 times. Jack From brian.e.carpenter@gmail.com Wed Feb 9 13:44:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2C23A6A0F for ; Wed, 9 Feb 2011 13:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.441 X-Spam-Level: X-Spam-Status: No, score=-103.441 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aroWw8vddQH7 for ; Wed, 9 Feb 2011 13:44:52 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 44E4C3A6A0D for ; Wed, 9 Feb 2011 13:44:52 -0800 (PST) Received: by wyf23 with SMTP id 23so712001wyf.31 for ; Wed, 09 Feb 2011 13:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZQK95MwnfeJZzm7P0wCc7tEYKq78i44KyAWohUqx9qM=; b=CMNq+CaJL6AVtMToUEXQt9xBYPCDIf4MN3O8IDDcgZpnzB2swLg9UD8OFZuqv+7nrn HtgqhsHeJjQmEses6JUQeC4Z9fO+MRFYse879z+hwzbHFv285xyI5dFzk5/P7mtyHirW jYyTAxX7dPiJbBnQlvl7Ao8Q6GSN4Sqoehv/g= 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=OR+RaEJJ0TuK4Ujk9M/Bl3wu/cit0Gn7qoMbxBNWVTQX67O8fNTeSy+AkO8v6O+/eB TjsQZJNoRhZaadC1AlC6jKEifsjfj0s5ljF+JsoSLHz0dhXH76QBSoYdGiFRcQUMN61+ c51usH8kj/Zt6zrWqJn+gQtcvjlY2rSUkV4Yg= Received: by 10.227.154.147 with SMTP id o19mr6058730wbw.149.1297287892283; Wed, 09 Feb 2011 13:44:52 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id r80sm433540wei.39.2011.02.09.13.44.48 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 13:44:51 -0800 (PST) Message-ID: <4D530ACD.4060002@gmail.com> Date: Thu, 10 Feb 2011 10:44:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops , Daniel Roesen , Keith Moore Subject: Re: [v6ops] Disable 6to4 by default but don't deprecate Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:44:53 -0000 On 2011-02-09 22:57, R=C3=A9mi Despr=C3=A9s wrote: > Le 9 f=C3=A9vr. 2011 =C3=A0 00:34, Keith Moore a =C3=A9crit : >=20 >> ... There's definitely an ideology that use of 6to4 is somehow not le= gitimate and that it's therefore acceptable to sabotage it rather than to= try to fix it. >=20 > Would you accept a recommendation that, from now on, 6to4 should be dis= abled by default. >=20 > Thus: =20 > - Users who know what they do, and keep or turn 6to4 on, won't feel cri= ticized by IETF > - The message being clear enough, completely deprecating 6to4 would bec= ome an unnecessary overreaction. >=20 Despite Keith's counter arguments, from what I've read here and on other lists, I am going this way in my draft. Certainly, ICMP 'destination unreachable' should be returned but it seems= that most 6to4 implementations don't react appropriately to this, and I think = it's too late to expect those code bases to be updated. Brian From moore@network-heretics.com Wed Feb 9 13:48:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C6A3A6866 for ; Wed, 9 Feb 2011 13:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eZ+2eqHYYXC for ; Wed, 9 Feb 2011 13:48:08 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 0F6BF3A6823 for ; Wed, 9 Feb 2011 13:48:05 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PnHtX-0005zW-7v; Wed, 09 Feb 2011 16:48:16 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: <4D530ACD.4060002@gmail.com> Date: Wed, 9 Feb 2011 16:48:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <35632143-C475-447D-8B21-E67EA8AF52E2@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <4D530ACD.4060002@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940677cce641d2e96b9aa537e4a42e24df6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops v6ops , Daniel Roesen Subject: Re: [v6ops] Disable 6to4 by default but don't deprecate Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:48:09 -0000 On Feb 9, 2011, at 4:44 PM, Brian E Carpenter wrote: > On 2011-02-09 22:57, R=E9mi Despr=E9s wrote: >> Le 9 f=E9vr. 2011 =E0 00:34, Keith Moore a =E9crit : >>=20 >>> ... There's definitely an ideology that use of 6to4 is somehow not = legitimate and that it's therefore acceptable to sabotage it rather than = to try to fix it. >>=20 >> Would you accept a recommendation that, from now on, 6to4 should be = disabled by default. >>=20 >> Thus: =20 >> - Users who know what they do, and keep or turn 6to4 on, won't feel = criticized by IETF >> - The message being clear enough, completely deprecating 6to4 would = become an unnecessary overreaction. >>=20 >=20 > Despite Keith's counter arguments, from what I've read here and on = other > lists, I am going this way in my draft. >=20 > Certainly, ICMP 'destination unreachable' should be returned but it = seems that > most 6to4 implementations don't react appropriately to this, and I = think it's too > late to expect those code bases to be updated. but somehow it's not too late to expect the same code bases to be = updated to disable 6to4 by default? Keith From brian.e.carpenter@gmail.com Wed Feb 9 13:57:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F9D3A6A06 for ; Wed, 9 Feb 2011 13:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.284 X-Spam-Level: X-Spam-Status: No, score=-103.284 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcf9FYeX7iR4 for ; Wed, 9 Feb 2011 13:57:13 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id C5A4E3A6823 for ; Wed, 9 Feb 2011 13:57:12 -0800 (PST) Received: by wyf23 with SMTP id 23so723490wyf.31 for ; Wed, 09 Feb 2011 13:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0uG/j684wmZDoMPTBOM2UlcsLOFOGAZE5D+BkCznonM=; b=GYKAtzq/oXYxtXO+9rDQs+NufKv7smd/qkLiemAGeXj4bvcQ54eDPW3fyION1+dKh6 OxHlnlnMqwAVF/Qm61fthHwkIqdGCvNC6IZj2Npg2YleLKouDeefphx0Md5CNzxGtgfK Paq0gibZPOHPeY7ZyiO+l8xwhJ7HaGLyxTjl0= 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=kxZS+x0Mr7MIRDkyNwxJLBwtecAN76tzDnq5SVajy8/LDpofpkHx5tSUzs4kuKZQ9o U/xvEANgXFs8noZd9qKpzzdG+mbG5VM5FfjbDHV6aDrfFCjWBLbJn2W1Yp/kUazacZ/b Co2Lv0YftB1vrOpm7IQFWCCCifv5MTRCCXl3M= Received: by 10.227.128.75 with SMTP id j11mr19880761wbs.60.1297288642730; Wed, 09 Feb 2011 13:57:22 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id c54sm443588wer.6.2011.02.09.13.57.18 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 13:57:21 -0800 (PST) Message-ID: <4D530DBC.9000507@gmail.com> Date: Thu, 10 Feb 2011 10:57:16 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Keith Moore References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <4D530ACD.4060002@gmail.com> <35632143-C475-447D-8B21-E67EA8AF52E2@network-heretics.com> In-Reply-To: <35632143-C475-447D-8B21-E67EA8AF52E2@network-heretics.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops , Daniel Roesen Subject: Re: [v6ops] Disable 6to4 by default but don't deprecate Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:57:14 -0000 On 2011-02-10 10:48, Keith Moore wrote: > On Feb 9, 2011, at 4:44 PM, Brian E Carpenter wrote: >=20 >> On 2011-02-09 22:57, R=C3=A9mi Despr=C3=A9s wrote: >>> Le 9 f=C3=A9vr. 2011 =C3=A0 00:34, Keith Moore a =C3=A9crit : >>> >>>> ... There's definitely an ideology that use of 6to4 is somehow not = legitimate and that it's therefore acceptable to sabotage it rather than = to try to fix it. >>> Would you accept a recommendation that, from now on, 6to4 should be d= isabled by default. >>> >>> Thus: =20 >>> - Users who know what they do, and keep or turn 6to4 on, won't feel c= riticized by IETF >>> - The message being clear enough, completely deprecating 6to4 would b= ecome an unnecessary overreaction. >>> >> Despite Keith's counter arguments, from what I've read here and on oth= er >> lists, I am going this way in my draft. >> >> Certainly, ICMP 'destination unreachable' should be returned but it se= ems that >> most 6to4 implementations don't react appropriately to this, and I thi= nk it's too >> late to expect those code bases to be updated. >=20 > but somehow it's not too late to expect the same code bases to be updat= ed to disable 6to4 by default? That isn't in the code base - at least in Windoze, I suspect it's a regis= try setting, which appears as a default netsh interface ipv6 6to4 set state state=3Denabled (at least in XP; I haven't modernised:) Brian From dr@cluenet.de Wed Feb 9 14:09:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61BC13A6839 for ; Wed, 9 Feb 2011 14:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcT87-lXTcWi for ; Wed, 9 Feb 2011 14:09:00 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id D49523A67CF for ; Wed, 9 Feb 2011 14:08:59 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 947D41080B3; Wed, 9 Feb 2011 23:09:09 +0100 (CET) Date: Wed, 9 Feb 2011 23:09:09 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110209220909.GA3260@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <4D52DEDD.8060903@bogus.com> <20110209185025.GA22226@srv03.cluenet.de> <20110209194648.GA27666@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 22:09:01 -0000 On Wed, Feb 09, 2011 at 01:26:33PM -0800, Cameron Byrne wrote: > On Feb 9, 2011 11:46 AM, "Daniel Roesen" wrote: > > > > On Wed, Feb 09, 2011 at 11:29:05AM -0800, Cameron Byrne wrote: > > > BOGON IPv4 address on PC via 3G > > > > What is a "BOGON" address in that specific case? RFC1918? > > > > UK military range OK, so something that every heuristic considers a "globally unique IPv4 address" in the sense of RFC3056 requesting that as a prerequisite. Given that Windows 7 won't use 6to4 unless talking to another 6to4 remote system OR a v6-only remote system without any other IPv6 transport means, your results are just as expected. RFC3484. End hosts not implementing RFC3484 policy are of concern, especially when the CPE router is the one actually implementing 6to4. The simple end host logic "don't use my local 6to4 tunnel functionality in case my IPv4 address is RFC1918" won't cut it. The end host learns the 6to4-derrived IPv6 address from the CPE router and might prefer that 6to4 IPv6 (non-)connectivity over IPv4. So the problem probably boils down to what OSses properly implement RFC3484? BTW while we're talking Win7+6to4 (just stumbled over that): http://ryanvictory.com/posts/automating-6to4-adapter-removal-in-windows/ http://news.softpedia.com/news/Windows-7-Can-Create-New-6to4-Adapters-on-Every-Reboot-135518.shtml http://support.microsoft.com/kb/980486/ Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From v6ops@daork.net Wed Feb 9 14:18:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD6E3A683D for ; Wed, 9 Feb 2011 14:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqh35Taxi7TA for ; Wed, 9 Feb 2011 14:18:22 -0800 (PST) Received: from unobtainium.braintrust.co.nz (unobtainium.braintrust.co.nz [123.100.101.131]) by core3.amsl.com (Postfix) with ESMTP id 1E84E3A67F6 for ; Wed, 9 Feb 2011 14:18:22 -0800 (PST) Received: from [192.168.0.21] (unknown [121.98.191.176]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id 677D927686 for ; Thu, 10 Feb 2011 11:18:31 +1300 (NZDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Nathan Ward In-Reply-To: Date: Thu, 10 Feb 2011 11:18:31 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <711B15AE-2C69-4E88-9993-65BE46364621@daork.net> References: <4D52DEDD.8060903@bogus.com> <20110209185025.GA22226@srv03.cluenet.de> <20110209194648.GA27666@srv03.cluenet.de> To: IPv6 Operations X-Mailer: Apple Mail (2.1082) Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 22:18:23 -0000 On 10/02/2011, at 10:26 AM, Cameron Byrne wrote: >=20 > On Feb 9, 2011 11:46 AM, "Daniel Roesen" wrote: >>=20 >> On Wed, Feb 09, 2011 at 11:29:05AM -0800, Cameron Byrne wrote: >>> BOGON IPv4 address on PC via 3G >>=20 >> What is a "BOGON" address in that specific case? RFC1918? >>=20 >=20 > UK military range What 6to4 "client" software did you use? In San Francisco I talked about a 6to4 qualification mechanism which = would send several 6to4 packets to ensure that the "client" had a = non-NATted publicly reachable IPv4 address with protocol 41 open. Someone at MS - I forget who - stated that their 6to4 implementation = sends a test 6to4 message to check that the relay is reachable. I = believe Apple said they do a similar thing in their 6to4 CPE devices = (James?). I have not observed (or tried to observe) either of these = mechanisms personally. While not a complete solution to test 6to4 = health, this might be why you do not see a poor user experience. In addition, as Daniel Rosen mentions, RFC3484 probably plays a large = part, if your end host IPv6 stack implements RFC3484 and has a line in = there for 6to4. -- Nathan Ward= From jbates@brightok.net Wed Feb 9 14:44:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214533A6868 for ; Wed, 9 Feb 2011 14:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIRr74aPFe2l for ; Wed, 9 Feb 2011 14:44:25 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 5B5AF3A684F for ; Wed, 9 Feb 2011 14:44:25 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p19MiZBx002191 for ; Wed, 9 Feb 2011 16:44:35 -0600 (CST) Message-ID: <4D5318D3.8090102@brightok.net> Date: Wed, 09 Feb 2011 16:44:35 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: v6ops@ietf.org References: <4D52DEDD.8060903@bogus.com> <20110209185025.GA22226@srv03.cluenet.de> <20110209194648.GA27666@srv03.cluenet.de> <20110209220909.GA3260@srv03.cluenet.de> In-Reply-To: <20110209220909.GA3260@srv03.cluenet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 22:44:26 -0000 On 2/9/2011 4:09 PM, Daniel Roesen wrote: > End hosts not implementing RFC3484 policy are of concern, especially > when the CPE router is the one actually implementing 6to4. Keep in mind, Cameron is using a 3G network. CPE routers are less likely to appear, and even less that support 6to4. You are right on his results with RFC3484, but that's the point of the test. "A typical user connecting via 3G browsing dual stacked hosts." What works for 3G doesn't apply to landline. Jack From Roman.Arcea@orange.md Wed Feb 9 14:59:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE5133A67FA for ; Wed, 9 Feb 2011 14:59:21 -0800 (PST) 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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iroPNwv++bMV for ; Wed, 9 Feb 2011 14:59:21 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id A74963A67AC for ; Wed, 9 Feb 2011 14:59:20 -0800 (PST) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id 2476EC09E6E; Thu, 10 Feb 2011 00:59:25 +0200 (EET) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id 065F7C09E4F; Thu, 10 Feb 2011 00:59:25 +0200 (EET) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> References: <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com>, <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> X-Disclaimed: 1 From: Roman.Arcea@orange.md To: moore@network-heretics.com Message-ID: Date: Thu, 10 Feb 2011 00:59:24 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2 HF194 November 09, 2010 X-MIMETrack: Serialize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 02/10/2011 00:59:24, Serialize complete at 02/10/2011 00:59:24, Itemize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 02/10/2011 00:59:24, Serialize by Router on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 02/10/2011 00:59:25, Serialize complete at 02/10/2011 00:59:25 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, dr@cluenet.de Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 22:59:21 -0000 >>=A0Fact - Most users don't have enough IPv6 capable devices to move to >using primarily IPv6 (let alone >>=A0IPv6-only) anytime soon > >Really? =A0 All of the major OS vendors have been shipping IPv6 support >for several years now. =A0Sure, there are still a few people running >Win 2k, me, 98, or even 95, but not many. Really? IPv6 service on our mobile network is available today! Have you hea= rd of any USB sticks that would play nicely with it? So, you are definitely wrong! The situation is very different from an ISP t= o another, but for mobile today, I can give service, but there is almost no= one to be able to get it. It's amazing how many people can't still figure = it out. Best, Roman= From dr@cluenet.de Wed Feb 9 15:03:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FEC83A67AC for ; Wed, 9 Feb 2011 15:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiolbIpNx-M9 for ; Wed, 9 Feb 2011 15:03:38 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 6B8743A65A6 for ; Wed, 9 Feb 2011 15:03:38 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 9732D1080B9; Thu, 10 Feb 2011 00:03:48 +0100 (CET) Date: Thu, 10 Feb 2011 00:03:48 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110209230348.GB6527@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <4D52DEDD.8060903@bogus.com> <20110209185025.GA22226@srv03.cluenet.de> <20110209194648.GA27666@srv03.cluenet.de> <20110209220909.GA3260@srv03.cluenet.de> <4D5318D3.8090102@brightok.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D5318D3.8090102@brightok.net> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] LSN breaking 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 23:03:39 -0000 On Wed, Feb 09, 2011 at 04:44:35PM -0600, Jack Bates wrote: > On 2/9/2011 4:09 PM, Daniel Roesen wrote: > Keep in mind, Cameron is using a 3G network. CPE routers are less likely to > appear, and even less that support 6to4. > > You are right on his results with RFC3484, but that's the point of the > test. "A typical user connecting via 3G browsing dual stacked hosts." Indeed, in networks where users attach without a router directly to "the net" will probably have no significant issues as long as the hosts implement RFC3484. No matter wether that access network is 3G or e.g. DOCSIS with host directly connected to the cable modem, WiFi hotspots, etc. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From joelja@bogus.com Wed Feb 9 15:14:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56CF3A672E for ; Wed, 9 Feb 2011 15:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlYT7N6B6niw for ; Wed, 9 Feb 2011 15:14:59 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id AFA363A65A6 for ; Wed, 9 Feb 2011 15:14:58 -0800 (PST) Received: from dhcp-176.nokia.net (dhcp-176.nokia.net [192.103.16.176] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p19NF2h1081767 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 9 Feb 2011 23:15:02 GMT (envelope-from joelja@bogus.com) Message-ID: <4D531FF5.7080306@bogus.com> Date: Wed, 09 Feb 2011 15:15:01 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Roman.Arcea@orange.md References: <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com>, <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.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, dr@cluenet.de, moore@network-heretics.com Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 23:14:59 -0000 On 2/9/11 2:59 PM, Roman.Arcea@orange.md wrote: >>> Fact - Most users don't have enough IPv6 capable devices to move >>> to >> using primarily IPv6 (let alone >>> IPv6-only) anytime soon >> >> Really? All of the major OS vendors have been shipping IPv6 >> support for several years now. Sure, there are still a few people >> running Win 2k, me, 98, or even 95, but not many. > > Really? IPv6 service on our mobile network is available today! Have > you heard of any USB sticks that would play nicely with it? So, you > are definitely wrong! The situation is very different from an ISP to > another, but for mobile today, I can give service, but there is > almost no one to be able to get it. It's amazing how many people > can't still figure it out. lg and huawei both now have products that fit that particular requirement... As with most carrier supported/launched mobile products, they build to their customer requirements... And you know as well as anyone where chipset supports stands. as to other members of the choir, the OSes already support it, legacy baseband radio controllers not so much. That's fine it's in their roadmaps and by the time you've got a v6 supporting mobile network widely deployed you'll presumably have products to put on it. > Best, Roman _______________________________________________ v6ops > mailing list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Roman.Arcea@orange.md Wed Feb 9 15:37:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E08EC3A672E for ; Wed, 9 Feb 2011 15:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0LMbalWbtQb for ; Wed, 9 Feb 2011 15:37:20 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id 093B83A65A6 for ; Wed, 9 Feb 2011 15:37:20 -0800 (PST) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id B91F7B18003; Thu, 10 Feb 2011 01:37:28 +0200 (EET) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id A2B46C09D5E; Thu, 10 Feb 2011 01:37:28 +0200 (EET) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <4D531FF5.7080306@bogus.com> References: <4D531FF5.7080306@bogus.com>, <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com>, <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> X-Disclaimed: 1 From: Roman.Arcea@orange.md To: joelja@bogus.com Message-ID: Date: Thu, 10 Feb 2011 01:37:28 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2 HF194 November 09, 2010 X-MIMETrack: Serialize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 02/10/2011 01:37:28, Serialize complete at 02/10/2011 01:37:28, Itemize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 02/10/2011 01:37:28, Serialize by Router on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 02/10/2011 01:37:28 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, dr@cluenet.de, moore@network-heretics.com Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 23:37:21 -0000 >as to other members of the choir, the OSes already support it, legacy >baseband radio controllers not so much. That's fine it's in their >roadmaps and by the time you've got a v6 supporting mobile network >widely deployed you'll presumably have products to put on it. the time for IPv6 was unfortunately yesterday, and today, the "presumably" = is simply not good enough. Otherwise, thanks for being optimistic :) Best, Roman= From joelja@bogus.com Wed Feb 9 16:06:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8C63A67AC for ; Wed, 9 Feb 2011 16:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qNYj-r9+-WH for ; Wed, 9 Feb 2011 16:06:55 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id C09FA3A67AD for ; Wed, 9 Feb 2011 16:06:54 -0800 (PST) Received: from dhcp-176.nokia.net (dhcp-176.nokia.net [192.103.16.176] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p1A06wx2084867 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 10 Feb 2011 00:06:58 GMT (envelope-from joelja@bogus.com) Message-ID: <4D532C22.9050507@bogus.com> Date: Wed, 09 Feb 2011 16:06:58 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Roman.Arcea@orange.md References: <4D531FF5.7080306@bogus.com>, <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com>, <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.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, dr@cluenet.de, moore@network-heretics.com Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 00:06:55 -0000 On 2/9/11 3:37 PM, Roman.Arcea@orange.md wrote: > >> as to other members of the choir, the OSes already support it, legacy >> baseband radio controllers not so much. That's fine it's in their >> roadmaps and by the time you've got a v6 supporting mobile network >> widely deployed you'll presumably have products to put on it. > > the time for IPv6 was unfortunately yesterday, and today, the "presumably" is simply not good enough. > Otherwise, thanks for being optimistic :) I shouldn't talk about specifics with other manufacturers but my employer has a lovely white paper on using ipv6 with our devices on forum nokia, some devices in the porfolio have supported it since 2005. your NSN account rep can probably cover the details of deployment better than I can. > Best, > Roman > From brian.e.carpenter@gmail.com Wed Feb 9 16:40:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7543D3A67F3 for ; Wed, 9 Feb 2011 16:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.551 X-Spam-Level: X-Spam-Status: No, score=-103.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cc9waCUtG2Z0 for ; Wed, 9 Feb 2011 16:40:15 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 8CFFB3A67AD for ; Wed, 9 Feb 2011 16:40:15 -0800 (PST) Received: by vws7 with SMTP id 7so527689vws.31 for ; Wed, 09 Feb 2011 16:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=1/x32TKgSYI/QqGLK6da61h/6FV6yirHHSEHv9kibyU=; b=d76yQoEvxniCXKeM7uPoIi9/jchM0tgybXxaCSv1qP+TLQee4U5hV7uzRSRNawWhJ2 hACz7xfUzeflyWUacdPYqWMWruHK1apF4AyB2EC+9ws8tmh8K/7FbzEbwBnVunmkFrnw 0hx2rD9Me5tLGsvQUAFF/Qje563j0VyQl0fOY= 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=cdWHq5GKh5e2wOooMQdnBQElQt9/MPe26jOACQDDMlgt0MzXJKYN+v4aD/O1yTMY9P sGaqvZ3iPQJam5Xa/gpkMIeTgIkaE2UKlMtM7lC6GD8xySIAUFigyWoPmUHgnJOTnXdp U6yFK+J4TCj9XVJr2m5KLrblEYPFoKrX6WDBI= Received: by 10.220.75.20 with SMTP id w20mr5589692vcj.34.1297298424721; Wed, 09 Feb 2011 16:40:24 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id i14sm363879vcr.11.2011.02.09.16.40.23 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 16:40:24 -0800 (PST) Message-ID: <4D5333EE.9000302@gmail.com> Date: Thu, 10 Feb 2011 13:40:14 +1300 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=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 00:40:16 -0000 Since there have been one or two messages on this topic, I've updated the draft already. There are quite a lot of changes. I'm considering removing Teredo completely and leaving that to be a separate draft. There seems to be plenty to say about 6to4 on its own. More comments are welcome, but please please please choose a new subject header for each topic; if you don't do this and we get another few hundred messages under the same subject, the chances that your point will be noticed are very small. Brian -------- Original Message -------- Subject: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-01.txt Date: Wed, 09 Feb 2011 16:30:01 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Advisory Guidelines for 6to4 and Teredo Deployment Author(s) : B. Carpenter Filename : draft-carpenter-v6ops-6to4-teredo-advisory-01.txt Pages : 18 Date : 2011-02-09 This document provides advice to network operators about deployment of two techniques for automatic tunneling of IPv6 over IPv4, namely 6to4 and Teredo. It is principally addressed to Internet Service Providers, including those that do not yet support IPv6, and to Content Providers. 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-carpenter-v6ops-6to4-teredo-advisory-01.txt From brian.e.carpenter@gmail.com Wed Feb 9 16:53:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67353A6826 for ; Wed, 9 Feb 2011 16:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.053 X-Spam-Level: X-Spam-Status: No, score=-103.053 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+u20zKFiuM4 for ; Wed, 9 Feb 2011 16:53:14 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 8B4613A67FA for ; Wed, 9 Feb 2011 16:53:14 -0800 (PST) Received: by vxi40 with SMTP id 40so419333vxi.31 for ; Wed, 09 Feb 2011 16:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=7s2ycVir+lHb1VMOvpTyoK7ar9iWA+BLVr9JsVnwok4=; b=PkS2YxAZOP/egdM8BmdfhNqFvq7rZgTdg9YQKatn4LbhqEu0j2VMAZMu74UW2JLb2W zDVbPRPimywJZcjMpPECwi/46of+HGPZBJDAPqN6BL9uZw52oBDyA5m68t66bYuDUJn+ BEXZ0v137uffZpBWpuNdsXtOacVsgOLXq9HuE= 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=aQaQIFP7DX2YRsOssUisCTcKj+C6UpJOffw+00LNpkawaV9GHUmC63vuKCL/FmYqgc lOzvNOD2WmnCrI3EaaP0s9iaTyU1PA+gDY1abr5cRc8SemgB7K6m1Df/xNruhu32PjZ6 EtcPEXlIM54kyxYhru1ycl1hZgYjw+YYbDndI= Received: by 10.220.182.76 with SMTP id cb12mr2371035vcb.19.1297299204903; Wed, 09 Feb 2011 16:53:24 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id v26sm368016vcr.13.2011.02.09.16.53.23 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 16:53:24 -0800 (PST) Message-ID: <4D5336F8.9080506@gmail.com> Date: Thu, 10 Feb 2011 13:53:12 +1300 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=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] draft-carpenter-v6ops-6to4-teredo-advisory-01 diffs from -00 version X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 00:53:15 -0000 http://tinyurl.com/6to4adv00-diffs More comments are welcome, but please please please choose a new subject header for each topic; if you don't do this and we get another few hundred messages under the same subject, the chances that your point will be noticed are very small. Brian From jhw@apple.com Wed Feb 9 17:37:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2A353A67FA for ; Wed, 9 Feb 2011 17:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaZSx-aV3+jB for ; Wed, 9 Feb 2011 17:37:21 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 059963A682B for ; Wed, 9 Feb 2011 17:37:21 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id C53A0CDDAB93 for ; Wed, 9 Feb 2011 17:37:14 -0800 (PST) X-AuditID: 11807134-b7c40ae000006cb9-ce-4d53414afef3 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay14.apple.com (Apple SCV relay) with SMTP id 8C.47.27833.A41435D4; Wed, 9 Feb 2011 17:37:14 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.14.84] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LGD00MEVOI20F00@et.apple.com> for v6ops@ietf.org; Wed, 09 Feb 2011 17:37:14 -0800 (PST) From: james woodyatt In-reply-to: <4D5336F8.9080506@gmail.com> Date: Wed, 09 Feb 2011 17:37:13 -0800 Message-id: <61F0E9D3-19D1-4F26-A167-022FBB618834@apple.com> References: <4D5336F8.9080506@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Operations Subject: [v6ops] 6to4 advisory draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 01:37:21 -0000 On Feb 9, 2011, at 16:53, Brian E Carpenter wrote: > > More comments are welcome, I recommend adding text to this draft recommending that well-managed 6to4 relays be capable of responding to ICMPv6 echo requests encapsulated in IPv4 protocol 41. The reason: certain CPE router products use ICMPv6 echo requests to detect the availability of a 6to4 relay at the anycast IPv4 address, and they will notify their users with a diagnostic message if they have 6to4 tunneled routing enabled and the relay is not responding to ICMPv6 echo requests, which is usually a sign that the anycast relay route is a black hole. Apple has found that some 6to4 relays work just fine, but ICMPv6 echo requests sent by the CPE router do not result in any replies received. The CPE router notifies the user there is a problem, but the user isn't *really* having a problem. The alarm is a false positive. The user then instructs the CPE router to stop sending the alarm, and then they don't get a notification when the relay stops working later. Proposed text: > Operators that deploy 6to4 relays are advised to ensure that ICMPv6 echo requests and replies encapsulated in IPv4 protocol 41 are passed properly between the relay and 6to4 hosts and routers for which it is intended to provide relay service. -- james woodyatt member of technical staff, core os networking From martin@millnert.se Wed Feb 9 17:59:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293483A682D for ; Wed, 9 Feb 2011 17:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYkCgfB-ahXs for ; Wed, 9 Feb 2011 17:59:24 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by core3.amsl.com (Postfix) with ESMTP id 46E9E3A67FA for ; Wed, 9 Feb 2011 17:59:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 6C85377A4; Thu, 10 Feb 2011 03:04:35 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wym3+S3u9sc9; Thu, 10 Feb 2011 03:04:35 +0100 (CET) Received: from [IPv6:2a02:9a0:100:2300::6] (shakira-work.us.millnert.se [IPv6:2a02:9a0:100:2300::6]) by ncis.csbnet.se (Postfix) with ESMTPSA id 4A47076C2; Thu, 10 Feb 2011 03:04:33 +0100 (CET) From: Martin Millnert To: Daniel Roesen In-Reply-To: <20110209220909.GA3260@srv03.cluenet.de> References: <4D52DEDD.8060903@bogus.com> <20110209185025.GA22226@srv03.cluenet.de> <20110209194648.GA27666@srv03.cluenet.de> <20110209220909.GA3260@srv03.cluenet.de> Content-Type: text/plain; charset="UTF-8" Date: Wed, 09 Feb 2011 20:59:27 -0500 Message-ID: <1297303167.18797.99.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] Equivalent & better solution for OS vendors to disabling 6to4 by default on already installed systems? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 01:59:26 -0000 Daniel, list, On Wed, 2011-02-09 at 23:09 +0100, Daniel Roesen wrote: > The end host learns the > 6to4-derrived IPv6 address from the CPE router and might prefer that > 6to4 IPv6 (non-)connectivity over IPv4. While programming bugs are inevitable, I don't see why this should happen. Given 6to4:s overall operational status, 1918 IPv4 should be preferred over 2002::/16. Are you saying it's not in some configurations? Put differently, 2002::/16 source addresses should obviously be used when it's the only global-scoped v6 source address available, when connecting to a global-scoped v6-only destination. Please tell me this is already the case! :) (can't test this now) > So the problem probably boils down to what OSses properly implement > RFC3484? Yes. And those that don't should get updated, frankly. It's important. The future depends on it. (and so on) If it is in fact only broken 3484 implementations causing all the 6to4 breakage we hear about, we should find a way to make this prioritized highly enough that OS:es not yet passed end-of-support receives an update. Though I'd be surprised if this wasn't mentioned by someone else at least 5 years ago though, and nobody listened... It'd be a very cool way for Microsoft and Apple to participate in World IPv6 day for sure! (Seriously.) > BTW while we're talking Win7+6to4 (just stumbled over that): > http://ryanvictory.com/posts/automating-6to4-adapter-removal-in-windows/ > http://news.softpedia.com/news/Windows-7-Can-Create-New-6to4-Adapters-on-Every-Reboot-135518.shtml > http://support.microsoft.com/kb/980486/ I've seen this myself, "adapter #56". (There are other implementation/programming bugs in Win7's stack as well, I emailed either v6ops or ipv6-ops with this last year. ) /M From jouni.nospam@gmail.com Wed Feb 9 21:46:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354E33A6896 for ; Wed, 9 Feb 2011 21:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFMpRUkbB33w for ; Wed, 9 Feb 2011 21:46:32 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 1FA5B3A6891 for ; Wed, 9 Feb 2011 21:46:31 -0800 (PST) Received: by bwz12 with SMTP id 12so1885266bwz.31 for ; Wed, 09 Feb 2011 21:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:references:to:message-id:mime-version:x-mailer; bh=Yowr9HMvmsSBfBY4ooNJm1RtrjNQZ5KGawJP2z5JAsc=; b=nNLJV/NfNi2aDGRtbDwX56EXNvKsxSssjaRVgOjG4ruK1ehSX071iNtFyL37oC2nKd CH0uIdrj0wIWKwdMD/w7j4E92R9oHX8uiFvATl1+HuEYrXg8YU3B58fTWABLSINmdu3j rjYus1rkypwSNczsDZOpn+8LyT/UiiO+mhwoA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; b=b7+rp0hJHU2nLzSwz/JnsSrtVcM/F9/UL2E07C0d/fGsX31y+fYU8TXs72Obgv8zca KiWf1BGzpDE/8uAGpm/FoIlT6DBZF/5brIBNoaSZ7USxLUj2aVoF9el/P6RN4AdV2h9v 4SM/dRhxjkjKM+A2Mp0/5r6ywzMhk66zOjsU4= Received: by 10.204.72.194 with SMTP id n2mr13445256bkj.128.1297316802133; Wed, 09 Feb 2011 21:46:42 -0800 (PST) Received: from a88-112-143-79.elisa-laajakaista.fi (a88-112-143-79.elisa-laajakaista.fi [88.112.143.79]) by mx.google.com with ESMTPS id j11sm707243bka.0.2011.02.09.21.46.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 21:46:41 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Feb 2011 07:46:26 +0200 References: <20110210053001.15959.10691.idtracker@localhost> To: IPv6 Operations Message-Id: Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [v6ops] Fwd: I-D Action:draft-korhonen-v6ops-3gpp-eps-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 05:46:33 -0000 Folks, We made some adjustments based on the latest commentary. The changes are = mainly in the Section 8.x and 5.2. - Jouni Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: February 10, 2011 7:30:01 AM GMT+02:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-korhonen-v6ops-3gpp-eps-06.txt > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : IPv6 in 3GPP Evolved Packet System > Author(s) : J. Korhonen, et al. > Filename : draft-korhonen-v6ops-3gpp-eps-06.txt > Pages : 31 > Date : 2011-02-09 >=20 > Internet connectivity and use of data services in 3GPP based mobile > networks has increased rapidly as a result of smart phones, broadband > service via HSPA and HSPA+ networks, competitive service offerings by > operators and a large number of applications. Operators who have > deployed networks based on 3GPP architectures are facing IPv4 address > shortages. With the impending exhaustion of available IPv4 addresses > from the registries there is an increased emphasis for operators to > migrate to IPv6. This document describes the support for IPv6 in > 3GPP network architectures. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-korhonen-v6ops-3gpp-eps-06.txt From Roman.Arcea@orange.md Wed Feb 9 22:05:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187773A6881 for ; Wed, 9 Feb 2011 22:05:57 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kbm3vxae+gGu for ; Wed, 9 Feb 2011 22:05:56 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id 9C2EE3A68A8 for ; Wed, 9 Feb 2011 22:05:55 -0800 (PST) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id A976FB18003; Thu, 10 Feb 2011 08:06:06 +0200 (EET) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id 941F8C0A262; Thu, 10 Feb 2011 08:06:06 +0200 (EET) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <4D532C22.9050507@bogus.com> References: <4D532C22.9050507@bogus.com>, <4D531FF5.7080306@bogus.com>, <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com>, <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> X-Disclaimed: 1 From: Roman.Arcea@orange.md To: joelja@bogus.com Message-ID: Date: Thu, 10 Feb 2011 08:06:06 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2 HF194 November 09, 2010 X-MIMETrack: Serialize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 02/10/2011 08:06:06, Serialize complete at 02/10/2011 08:06:06, Itemize by HTTP Server on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 02/10/2011 08:06:06, Serialize by Router on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 02/10/2011 08:06:06 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, dr@cluenet.de, moore@network-heretics.com Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 06:05:57 -0000 >On 2/9/11 3:37 PM, Roman.Arcea@orange.md wrote: >> >>>=A0as to other members of the choir, the OSes already support it, >legacy >>>=A0baseband radio controllers not so much. That's fine it's in their >>>=A0roadmaps and by the time you've got a v6 supporting mobile network >>>=A0widely deployed you'll presumably have products to put on it. >> >>=A0the time for IPv6 was unfortunately yesterday, and today, the >"presumably" is simply not good enough. >>=A0Otherwise, thanks for being optimistic :) > >I shouldn't talk about specifics with other manufacturers but my >employer has a lovely white paper on using ipv6 with our devices on >forum nokia, some devices in the porfolio have supported it since >2005. >your NSN account rep can probably cover the details of deployment >better >than I can. I am well aware of your employers support of IPv6 in both core and handsets= . Thanks to the former, people who have ever deployed things in the mobile = core, were as well able to take it out of pure theory and test it. It is re= ally appreciated. The scope of my message was to point out to some of the folks on the list t= hat are so eagerly talking about pervasive IPv6 support that for some busin= esses the current technical model does not imply plugging in an Ethernet ca= ble and rely on OS support alone. This makes it a huge deal breaker. For the rest of this huge thread, I agree with Remi conclusions. 6to4 shoul= d be shut down by default. Even putting it to the bottom by a policy alone = does not save it from issues with bogon space. Otherwise, as a mechanism, i= t might be there as a last resort for tech savvy customers. On the other hand I can't agree more with James Woodyatt. Manufacturers wil= l not modify the existing state of art if we deprecate 6to4. As well as I a= m not gonna shut down the 6to4 anycast relay. The point is just to make sur= e manufacturers don't put as many resources in maintaining 6to4, and would = rather focus on a better support of IPv6 stack, management over IPv6 etc. Best, Roman From pekkas@netcore.fi Wed Feb 9 22:20:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190113A6881 for ; Wed, 9 Feb 2011 22:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJhNWBbbrF9S for ; Wed, 9 Feb 2011 22:20:51 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 5DAE13A68A7 for ; Wed, 9 Feb 2011 22:20:51 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p1A6KoG3009647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Feb 2011 08:20:50 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p1A6Kmx0009643; Thu, 10 Feb 2011 08:20:48 +0200 Date: Thu, 10 Feb 2011 08:20:48 +0200 (EET) From: Pekka Savola To: james woodyatt In-Reply-To: <61F0E9D3-19D1-4F26-A167-022FBB618834@apple.com> Message-ID: References: <4D5336F8.9080506@gmail.com> <61F0E9D3-19D1-4F26-A167-022FBB618834@apple.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: IPv6 Operations Subject: Re: [v6ops] 6to4 advisory draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 06:20:53 -0000 On Wed, 9 Feb 2011, james woodyatt wrote: > I recommend adding text to this draft recommending that well-managed > 6to4 relays be capable of responding to ICMPv6 echo requests > encapsulated in IPv4 protocol 41. Which IPv6 address should the relay be responding pings at? This was actually a topic of a draft some 8 years ago but didn't go anywhere. Just send the echo request with TTL=1 like Microsoft implementation does, and whether you receive a reply -- TTL exceeded or a response -- is enough. -- 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 moore@network-heretics.com Wed Feb 9 22:39:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29FC63A68A9 for ; Wed, 9 Feb 2011 22:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zM5WPTfeomVb for ; Wed, 9 Feb 2011 22:39:27 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id DC5433A68A7 for ; Wed, 9 Feb 2011 22:39:26 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PnQBl-0002xY-6R; Thu, 10 Feb 2011 01:39:37 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: <4D530DBC.9000507@gmail.com> Date: Thu, 10 Feb 2011 01:39:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <4D530ACD.4060002@gmail.com> <35632143-C475-447D-8B21-E67EA8AF52E2@network-heretics.com> <4D530DBC.9000507@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940716e8753ffe8183434eacca5f930cb95350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops v6ops , Daniel Roesen Subject: Re: [v6ops] Disable 6to4 by default but don't deprecate Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 06:39:28 -0000 On Feb 9, 2011, at 4:57 PM, Brian E Carpenter wrote: > On 2011-02-10 10:48, Keith Moore wrote: >> On Feb 9, 2011, at 4:44 PM, Brian E Carpenter wrote: >>=20 >>> On 2011-02-09 22:57, R=E9mi Despr=E9s wrote: >>>> Le 9 f=E9vr. 2011 =E0 00:34, Keith Moore a =E9crit : >>>>=20 >>>>> ... There's definitely an ideology that use of 6to4 is somehow = not legitimate and that it's therefore acceptable to sabotage it rather = than to try to fix it. >>>> Would you accept a recommendation that, from now on, 6to4 should be = disabled by default. >>>>=20 >>>> Thus: =20 >>>> - Users who know what they do, and keep or turn 6to4 on, won't feel = criticized by IETF >>>> - The message being clear enough, completely deprecating 6to4 would = become an unnecessary overreaction. >>>>=20 >>> Despite Keith's counter arguments, from what I've read here and on = other >>> lists, I am going this way in my draft. >>>=20 >>> Certainly, ICMP 'destination unreachable' should be returned but it = seems that >>> most 6to4 implementations don't react appropriately to this, and I = think it's too >>> late to expect those code bases to be updated. >>=20 >> but somehow it's not too late to expect the same code bases to be = updated to disable 6to4 by default? >=20 > That isn't in the code base - at least in Windoze, I suspect it's a = registry > setting, which appears as a default > netsh interface ipv6 6to4 set state state=3Denabled > (at least in XP; I haven't modernised:) maybe so. and Windows is the single biggest variable, of course.=20 Keith From moore@network-heretics.com Wed Feb 9 22:43:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DB073A68B6 for ; Wed, 9 Feb 2011 22:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYO3crcp0hKA for ; Wed, 9 Feb 2011 22:43:44 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 71C293A68B0 for ; Wed, 9 Feb 2011 22:43:44 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PnQFt-0005IR-VX; Thu, 10 Feb 2011 01:43:54 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore X-Priority: 3 (Normal) In-Reply-To: Date: Thu, 10 Feb 2011 01:43:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7F803C23-D010-442D-8A67-D9ADACE92C95@network-heretics.com> References: <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com>, <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> To: Roman.Arcea@orange.md X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940a908c2e41f342d3713d6bb8a6ca6ff96350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, dr@cluenet.de Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 06:43:46 -0000 On Feb 9, 2011, at 5:59 PM, Roman.Arcea@orange.md wrote: >>> Fact - Most users don't have enough IPv6 capable devices to move to >> using primarily IPv6 (let alone >>> IPv6-only) anytime soon >>=20 >> Really? All of the major OS vendors have been shipping IPv6 support >> for several years now. Sure, there are still a few people running >> Win 2k, me, 98, or even 95, but not many. >=20 > Really? IPv6 service on our mobile network is available today! Have = you heard of any USB sticks that would play nicely with it? I'm not sufficiently familiar with either your network or USB sticks = that might work with your network, to know one way or the other. (I have to wonder, why would a USB stick care whether it's sending v4 or = v6? Shouldn't it be operating at L2? Is it really the USB stick that's = the problem, or the host device driver?) Keith From Roman.Arcea@orange.md Wed Feb 9 22:58:18 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A45D3A685D for ; Wed, 9 Feb 2011 22:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKwWa-XuG7VI for ; Wed, 9 Feb 2011 22:58:17 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by core3.amsl.com (Postfix) with ESMTP id EA15E3A68C6 for ; Wed, 9 Feb 2011 22:58:16 -0800 (PST) Received: from mailfilter.orange.md (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with SMTP id AF0B1C0A2C4; Thu, 10 Feb 2011 08:58:16 +0200 (EET) Received: from postman.orange.md (unknown [172.16.1.6]) by mailfilter.orange.md (Postfix) with ESMTP id 94ECCC0A262; Thu, 10 Feb 2011 08:58:16 +0200 (EET) In-Reply-To: <7F803C23-D010-442D-8A67-D9ADACE92C95@network-heretics.com> References: <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> To: Keith Moore MIME-Version: 1.0 X-KeepSent: D500184F:74FCADCF-C2257833:00260646; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Roman.Arcea@orange.md Date: Thu, 10 Feb 2011 08:58:14 +0200 X-MIMETrack: Serialize by Router on postman/OrangeMD(Release 8.5.2 HF194|November 09, 2010) at 02/10/2011 08:58:17, Serialize complete at 02/10/2011 08:58:17 Content-Type: text/plain; charset="US-ASCII" Cc: v6ops@ietf.org, dr@cluenet.de Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 06:58:18 -0000 Keith Moore wrote on 10-02-2011 08:43:50: > From: Keith Moore > To: Roman.Arcea@orange.md > Cc: dr@cluenet.de, v6ops@ietf.org, Wesley.E.George@sprint.com > Date: 10-02-11 08:44 > Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan- > v6ops-6to4-to-historic-00 > > On Feb 9, 2011, at 5:59 PM, Roman.Arcea@orange.md wrote: > >>> Fact - Most users don't have enough IPv6 capable devices to move to > >> using primarily IPv6 (let alone > >>> IPv6-only) anytime soon > >> > >> Really? All of the major OS vendors have been shipping IPv6 support > >> for several years now. Sure, there are still a few people running > >> Win 2k, me, 98, or even 95, but not many. > > > > Really? IPv6 service on our mobile network is available today! > Have you heard of any USB sticks that would play nicely with it? > I'm not sufficiently familiar with either your network or USB sticks > that might work with your network, to know one way or the other. > (I have to wonder, why would a USB stick care whether it's sending > v4 or v6? Shouldn't it be operating at L2? Is it really the USB > stick that's the problem, or the host device driver?) The radio controllers are the issue. The entire worldwide user base is not upgradeable to IPv6 as a result. I know, this is very weird. And it is not only about USB sticks, but about mobile phones as well. Exception are 2 manufacturers. From moore@network-heretics.com Wed Feb 9 22:59:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767253A68CD for ; Wed, 9 Feb 2011 22:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMU4u6-o6DFW for ; Wed, 9 Feb 2011 22:59:09 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 660C13A685D for ; Wed, 9 Feb 2011 22:59:08 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PnQUo-0005jM-T2; Thu, 10 Feb 2011 01:59:19 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: <4D530ACD.4060002@gmail.com> Date: Thu, 10 Feb 2011 01:59:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <4D530ACD.4060002@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940166a40e30b421ae8b58c01f77657fdc4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops v6ops , Daniel Roesen Subject: Re: [v6ops] Disable 6to4 by default but don't deprecate Re: Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 06:59:10 -0000 On Feb 9, 2011, at 4:44 PM, Brian E Carpenter wrote: > On 2011-02-09 22:57, R=E9mi Despr=E9s wrote: >> Le 9 f=E9vr. 2011 =E0 00:34, Keith Moore a =E9crit : >>=20 >>> ... There's definitely an ideology that use of 6to4 is somehow not = legitimate and that it's therefore acceptable to sabotage it rather than = to try to fix it. >>=20 >> Would you accept a recommendation that, from now on, 6to4 should be = disabled by default. >>=20 >> Thus: =20 >> - Users who know what they do, and keep or turn 6to4 on, won't feel = criticized by IETF >> - The message being clear enough, completely deprecating 6to4 would = become an unnecessary overreaction. >>=20 >=20 > Despite Keith's counter arguments, from what I've read here and on = other > lists, I am going this way in my draft. >=20 > Certainly, ICMP 'destination unreachable' should be returned but it = seems that > most 6to4 implementations don't react appropriately to this, and I = think it's too > late to expect those code bases to be updated. FWIW, I'm going to stop arguing against this. I'm now persuaded that = the soon-to-come wide deployment of carrier-provided NATs is going to = relegate 6to4's usefulness to corner cases. That doesn't make it = useless, and I think ISPs and content providers will still have to deal = with making sure that relay routers are working for some time to come. = But it does keep 6to4 from serving as a general-purpose way to use IPv6 = over a vanilla IPv4 connection. =20 I think it's a huge loss, and it will make v6 harder to deploy, but = nothing can be done about it. There's no way to make 6to4 work over a = bogon network without introducing NAT into IPv6, and that's a much worse = thing to do than forcing NAT onto v4. I'm also persuaded that - mostly due to CPE brain-damage - it's not = feasible to have a general mechanism for the network to tell end systems = to disable 6to4. =20 So on balance, I now think it makes sense to expect the users in those = corner cases to have to explicitly enable 6to4. Keith From moore@network-heretics.com Wed Feb 9 23:07:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DFCF3A68AF for ; Wed, 9 Feb 2011 23:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+qlarOVpt0v for ; Wed, 9 Feb 2011 23:07:15 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 867DE3A68AD for ; Wed, 9 Feb 2011 23:07:15 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PnQcf-0006Fj-9y; Thu, 10 Feb 2011 02:07:25 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <1297303167.18797.99.camel@shakira.millnert.se> Date: Thu, 10 Feb 2011 02:07:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D52DEDD.8060903@bogus.com> <20110209185025.GA22226@srv03.cluenet.de> <20110209194648.GA27666@srv03.cluenet.de> <20110209220909.GA3260@srv03.cluenet.de> <1297303167.18797.99.camel@shakira.millnert.se> To: Martin Millnert X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9403198054df37d4ccf6f9c82757c9cadf3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Equivalent & better solution for OS vendors to disabling 6to4 by default on already installed systems? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 07:07:17 -0000 On Feb 9, 2011, at 8:59 PM, Martin Millnert wrote: > On Wed, 2011-02-09 at 23:09 +0100, Daniel Roesen wrote: >> The end host learns the >> 6to4-derrived IPv6 address from the CPE router and might prefer that >> 6to4 IPv6 (non-)connectivity over IPv4. >=20 > While programming bugs are inevitable, I don't see why this should > happen. Given 6to4:s overall operational status, 1918 IPv4 should be > preferred over 2002::/16. disagree. there are situations where 6to4 will break. there are also a = lot of situations where NATs will break applications. whether to prefer = a NATted v4 connection over a 6to4 connection is application specific. Keith From moore@network-heretics.com Wed Feb 9 23:12:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D823A68A9 for ; Wed, 9 Feb 2011 23:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1go-nlkvVUry for ; Wed, 9 Feb 2011 23:12:20 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id C97943A68AC for ; Wed, 9 Feb 2011 23:12:19 -0800 (PST) Received: from [108.108.164.201] (helo=108-108-164-201.pools.spcsdns.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1PnQha-0007IS-66; Thu, 10 Feb 2011 02:12:30 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Thu, 10 Feb 2011 02:12:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> To: Roman.Arcea@orange.md X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940d7a664a639c59d7798979b696114ad06350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.108.164.201 Cc: v6ops@ietf.org, dr@cluenet.de Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 07:12:24 -0000 On Feb 10, 2011, at 1:58 AM, Roman.Arcea@orange.md wrote: >>> Really? IPv6 service on our mobile network is available today!=20 >> Have you heard of any USB sticks that would play nicely with it? >=20 >> I'm not sufficiently familiar with either your network or USB sticks >> that might work with your network, to know one way or the other. >=20 >> (I have to wonder, why would a USB stick care whether it's sending=20 >> v4 or v6? Shouldn't it be operating at L2? Is it really the USB=20 >> stick that's the problem, or the host device driver?) >=20 > The radio controllers are the issue. The entire worldwide user base is = not=20 > upgradeable to IPv6 as a result. I know, this is very weird. And it is = not=20 > only about USB sticks, but about mobile phones as well. Exception are = 2=20 > manufacturers. maybe there need to be DHCPv4 and/or PPP options that tell hosts/CPEs = how to configure their end of a v6-over-v4 tunnel, with the other end of = the tunnel provided by the network. it's probably too late for such a mechanism to be of general use across = all v4 networks, but for specific network layers it might be useful. Keith From dr@cluenet.de Wed Feb 9 23:21:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 884393A68A9 for ; Wed, 9 Feb 2011 23:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWUq7jrczjsc for ; Wed, 9 Feb 2011 23:21:23 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [195.20.121.100]) by core3.amsl.com (Postfix) with ESMTP id 6C53E3A68A6 for ; Wed, 9 Feb 2011 23:21:23 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 3A9A31080A0; Thu, 10 Feb 2011 08:21:04 +0100 (CET) Date: Thu, 10 Feb 2011 08:21:04 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110210072104.GA5220@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <4D5336F8.9080506@gmail.com> <61F0E9D3-19D1-4F26-A167-022FBB618834@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61F0E9D3-19D1-4F26-A167-022FBB618834@apple.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] 6to4 advisory draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 07:21:27 -0000 On Wed, Feb 09, 2011 at 05:37:13PM -0800, james woodyatt wrote: > I recommend adding text to this draft recommending that well-managed > 6to4 relays be capable of responding to ICMPv6 echo requests > encapsulated in IPv4 protocol 41. What is the destination address of the ICMPv6 echo request packet supposed to be, and what the echo reply source address? I think we should specify how those probes should look like. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From teemu.savolainen@nokia.com Thu Feb 10 04:58:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F5C93A6A12 for ; Thu, 10 Feb 2011 04:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BkwqwMq6sVV for ; Thu, 10 Feb 2011 04:58:16 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 9C1EC3A6A09 for ; Thu, 10 Feb 2011 04:58:16 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1ACwHSe022792; Thu, 10 Feb 2011 14:58:22 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Feb 2011 14:58:01 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 Feb 2011 13:58:01 +0100 Received: from 008-AM1MPN1-016.mgdnok.nokia.com ([169.254.6.185]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi; Thu, 10 Feb 2011 13:58:01 +0100 From: To: , Thread-Topic: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 Thread-Index: AQHLyK0RLlau08LCz0qdf1mdnCESO5P6OaIAgAB42KA= Date: Thu, 10 Feb 2011 12:57:59 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A31939BB6D@008-AM1MPN1-016.mgdnok.nokia.com> References: <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com>, <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com> <20110207175624.GA929@srv03.cluenet.de> <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com> <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <7F803C23-D010-442D-8A67-D9ADACE92C95@network-heretics.com> In-Reply-To: <7F803C23-D010-442D-8A67-D9ADACE92C95@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Feb 2011 12:58:01.0847 (UTC) FILETIME=[26475070:01CBC922] X-Nokia-AV: Clean Cc: v6ops@ietf.org, dr@cluenet.de Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 12:58:17 -0000 Keith, > (I have to wonder, why would a USB stick care whether it's sending v4 > or v6? Shouldn't it be operating at L2? Is it really the USB stick > that's the problem, or the host device driver?) In 3GPP architecture the L2 is actually aware of IPv4 and IPv6, as draft-ko= rhonen-v6ops-3gpp-eps-06.txt points out. Hence the requirement for USB stick to support IPv6 on L2. Best regards, Teemu From jhw@apple.com Thu Feb 10 07:46:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DED13A67B1 for ; Thu, 10 Feb 2011 07:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dspBuE0770cl for ; Thu, 10 Feb 2011 07:46:51 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id AF44B3A69FC for ; Thu, 10 Feb 2011 07:46:51 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 581F4D13FC8D for ; Thu, 10 Feb 2011 07:47:04 -0800 (PST) X-AuditID: 11807130-b7b3cae00000405d-e4-4d54087885c9 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay11.apple.com (Apple SCV relay) with SMTP id 3C.DE.16477.878045D4; Thu, 10 Feb 2011 07:47:04 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [172.16.1.19] (adit.conjury.org [75.101.54.88]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LGE003V5RUFCA50@gertie.apple.com> for v6ops@ietf.org; Thu, 10 Feb 2011 07:47:04 -0800 (PST) From: james woodyatt In-reply-to: <20110210072104.GA5220@srv03.cluenet.de> Date: Thu, 10 Feb 2011 07:47:02 -0800 Message-id: References: <4D5336F8.9080506@gmail.com> <61F0E9D3-19D1-4F26-A167-022FBB618834@apple.com> <20110210072104.GA5220@srv03.cluenet.de> To: IPv6 Operations X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] 6to4 advisory draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 15:46:53 -0000 On Feb 9, 2011, at 23:21, Daniel Roesen wrote: > On Wed, Feb 09, 2011 at 05:37:13PM -0800, james woodyatt wrote: >> I recommend adding text to this draft recommending that well-managed >> 6to4 relays be capable of responding to ICMPv6 echo requests >> encapsulated in IPv4 protocol 41. > > What is the destination address of the ICMPv6 echo request packet > supposed to be, and what the echo reply source address? I think we > should specify how those probes should look like. The implementation I'm familiar with sends IPv4 encapsulated echo requests to outer=192.88.99.1 and inner=[2002:c058:6301::] and wants to receive replies with a matching ICMPv6 identifier field from any source address. -- james woodyatt member of technical staff, core os networking From ichiroumakino@gmail.com Thu Feb 10 08:41:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9489E3A67AF for ; Thu, 10 Feb 2011 08:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaxfEpqgmkX6 for ; Thu, 10 Feb 2011 08:41:50 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id A66913A659A for ; Thu, 10 Feb 2011 08:41:49 -0800 (PST) Received: by wyf23 with SMTP id 23so1608659wyf.31 for ; Thu, 10 Feb 2011 08:42:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=zA41ip6BVRgLoSSo9GWdNnL/ijm9an26Kz+1zGgYf2o=; b=Bc1UX1nXHQLhjGLwVGQedVNoIgDyINGkNJy8o5qkmGeasz7DDlTWcoRqYHftrNjE2L QnaD/Nz4/B/6O+kz6KYD669SiU9Qao/Glq03synsx7NU+nDwkvHEo3mKVrYO9Oq/GM1J bg3AKmGMQ8deT6hGCc7k2+E20zlxUacQLGtKE= 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=LCjehHxEc9lwOtTS6ew/l1FpcW5MhAY+cWIzZO89iqRYxIIx51UIR3kYD71b/O8O2S NHfQX4V2+EvGHnB8RPttd84jChMb2YeBY0yPg/LKXjfq2FNfZUcgwKiAxLDGKkZB6Enx UmTO4hUINtrw4mnc79z7QjEFECodXn08o4gKs= Received: by 10.227.132.69 with SMTP id a5mr20985979wbt.123.1297356121575; Thu, 10 Feb 2011 08:42:01 -0800 (PST) Received: from dhcp-10-55-80-176.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id w25sm137228wbd.23.2011.02.10.08.42.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Feb 2011 08:42:00 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Thu, 10 Feb 2011 17:41:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9A021B97-EE91-437A-9C79-CFF7D4670B49@employees.org> References: <4D5336F8.9080506@gmail.com> <61F0E9D3-19D1-4F26-A167-022FBB618834@apple.com> To: Pekka Savola X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] 6to4 reliability check X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 16:41:50 -0000 >> I recommend adding text to this draft recommending that well-managed = 6to4 relays be capable of responding to ICMPv6 echo requests = encapsulated in IPv4 protocol 41. >=20 > Which IPv6 address should the relay be responding pings at? >=20 > This was actually a topic of a draft some 8 years ago but didn't go = anywhere. >=20 > Just send the echo request with TTL=3D1 like Microsoft implementation = does, and whether you receive a reply -- TTL exceeded or a response -- = is enough. >=20 can we not use the unreachability check from 6rd: http://tools.ietf.org/html/rfc5969#section-8 cheers, Ole= From pekkas@netcore.fi Thu Feb 10 08:55:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C62C3A67B4 for ; Thu, 10 Feb 2011 08:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08V2D5MBNsuK for ; Thu, 10 Feb 2011 08:55:01 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 65E143A6A25 for ; Thu, 10 Feb 2011 08:55:01 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p1AGt1bQ024754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Feb 2011 18:55:01 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p1AGt1LD024751; Thu, 10 Feb 2011 18:55:01 +0200 Date: Thu, 10 Feb 2011 18:55:01 +0200 (EET) From: Pekka Savola To: james woodyatt In-Reply-To: Message-ID: References: <4D5336F8.9080506@gmail.com> <61F0E9D3-19D1-4F26-A167-022FBB618834@apple.com> <20110210072104.GA5220@srv03.cluenet.de> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: IPv6 Operations Subject: Re: [v6ops] 6to4 reliability check X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 16:55:03 -0000 On Thu, 10 Feb 2011, james woodyatt wrote: > On Feb 9, 2011, at 23:21, Daniel Roesen wrote: >> On Wed, Feb 09, 2011 at 05:37:13PM -0800, james woodyatt wrote: >>> I recommend adding text to this draft recommending that well-managed >>> 6to4 relays be capable of responding to ICMPv6 echo requests >>> encapsulated in IPv4 protocol 41. >> >> What is the destination address of the ICMPv6 echo request packet >> supposed to be, and what the echo reply source address? I think we >> should specify how those probes should look like. > > The implementation I'm familiar with sends IPv4 encapsulated echo requests to outer=192.88.99.1 and inner=[2002:c058:6301::] and wants to receive replies with a matching ICMPv6 identifier field from any source address. This is suboptimal compared to the implementation I described and can be read about e.g. from http://netcore.fi/pekkas/6to4.pdf because the check you describe only succeeds if the relay is configured with 2002:c058:6301:: or supports subnet-router anycast address. Wrt Ole's mail, 6rd check seems like a self-ping procedure which may imply special requirements wrt. RPF checking (e.g. allow-self-ping special knob). In case of 6to4, the relay might drop the packet, depending on filtering. Relays should not be expecting to get traffic from 6to4 source addresses destined to 6to4 addresses. RFC3964 Section 5.2 recommends (SHOULD) dropping these. I'm not familiar if this is commonplace or not. -- 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 jhw@apple.com Thu Feb 10 10:15:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32843A67A4 for ; Thu, 10 Feb 2011 10:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMjpDlDDWJ6v for ; Thu, 10 Feb 2011 10:15:50 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 85A843A659A for ; Thu, 10 Feb 2011 10:15:49 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 70AD3CE14D5C for ; Thu, 10 Feb 2011 10:15:59 -0800 (PST) X-AuditID: 11807136-b7b89ae000000345-28-4d542b5f3f26 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay15.apple.com (Apple SCV relay) with SMTP id 1D.1E.00837.F5B245D4; Thu, 10 Feb 2011 10:15:59 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.14.84] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LGE008NZYQNL410@elliott.apple.com> for v6ops@ietf.org; Thu, 10 Feb 2011 10:15:59 -0800 (PST) From: james woodyatt In-reply-to: Date: Thu, 10 Feb 2011 10:15:58 -0800 Message-id: <09746C7E-1BB8-4DAD-9FE6-9FC05FE9AE87@apple.com> References: <4D5336F8.9080506@gmail.com> <61F0E9D3-19D1-4F26-A167-022FBB618834@apple.com> <20110210072104.GA5220@srv03.cluenet.de> To: Pekka Savola X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Operations Subject: Re: [v6ops] 6to4 reliability check X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 18:15:51 -0000 On Feb 10, 2011, at 08:55, Pekka Savola wrote: > On Thu, 10 Feb 2011, james woodyatt wrote: >> >> The implementation I'm familiar with sends IPv4 encapsulated echo requests to outer=192.88.99.1 and inner=[2002:c058:6301::] and wants to receive replies with a matching ICMPv6 identifier field from any source address. > > This is suboptimal... I agree. I'm not describing what should be done in the future, but rather what has already been done and shipped in large numbers around the world. We're talking about a terrain feature, remember? Yes, it would be nice if we had built a 5-star golf course where there is now a midge-infested swamp... Brian's advisory draft is aimed at telling operators how to help in draining the swamp, not how to keep the grass from dying on hypothetical fairways. -- james woodyatt member of technical staff, core os networking From pekkas@netcore.fi Thu Feb 10 10:21:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548E63A67A4 for ; Thu, 10 Feb 2011 10:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt8DVMsxTLPK for ; Thu, 10 Feb 2011 10:21:56 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 32C1E3A6987 for ; Thu, 10 Feb 2011 10:21:55 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p1AIM4gM026694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Feb 2011 20:22:04 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p1AIM4mI026691; Thu, 10 Feb 2011 20:22:04 +0200 Date: Thu, 10 Feb 2011 20:22:04 +0200 (EET) From: Pekka Savola To: james woodyatt In-Reply-To: <09746C7E-1BB8-4DAD-9FE6-9FC05FE9AE87@apple.com> Message-ID: References: <4D5336F8.9080506@gmail.com> <61F0E9D3-19D1-4F26-A167-022FBB618834@apple.com> <20110210072104.GA5220@srv03.cluenet.de> <09746C7E-1BB8-4DAD-9FE6-9FC05FE9AE87@apple.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.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: IPv6 Operations Subject: Re: [v6ops] 6to4 reliability check X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 18:21:57 -0000 On Thu, 10 Feb 2011, james woodyatt wrote: >> This is suboptimal... > > I agree. I'm not describing what should be done in the future, but > rather what has already been done and shipped in large numbers > around the world. We're talking about a terrain feature, remember? It is good to hear what some implementations have done. Even better would be hearing about the side effects. The more robust check I mentioned has been deployed and is being run by (dozens of?) millions of Windows boxes daily for at least 5+ years now. It's causing some load on the relays, but otherwise I suppose it works OK. -- 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 dr@cluenet.de Thu Feb 10 10:55:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1EDD3A6981 for ; Thu, 10 Feb 2011 10:55:55 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiveNP6nzc1h for ; Thu, 10 Feb 2011 10:55:55 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id DE1023A67AB for ; Thu, 10 Feb 2011 10:55:54 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 234CC1080C4; Thu, 10 Feb 2011 19:56:06 +0100 (CET) Date: Thu, 10 Feb 2011 19:56:06 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110210185606.GA14485@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <4D5336F8.9080506@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D5336F8.9080506@gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [v6ops] Carrier Grade NAT => ISP-operated NAT44 (NAT444 scenario) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 18:55:55 -0000 On Thu, Feb 10, 2011 at 01:53:12PM +1300, Brian E Carpenter wrote: > More comments are welcome, but please please please choose a new > subject header for each topic; if you don't do this and we get > another few hundred messages under the same subject, the chances that > your point will be noticed are very small. I would suggest replacing all references to the marketing term "Carrier Grade NAT" with "ISP-operated NAT44", depending on the context ammended by "(NAT444 scenario)" to more clearly specify the setting. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From brian.e.carpenter@gmail.com Thu Feb 10 11:37:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82AEF3A6981 for ; Thu, 10 Feb 2011 11:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHEg+kI0rSAK for ; Thu, 10 Feb 2011 11:37:35 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 97CC23A686A for ; Thu, 10 Feb 2011 11:37:35 -0800 (PST) Received: by fxm9 with SMTP id 9so2098347fxm.31 for ; Thu, 10 Feb 2011 11:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RtePvEKAi2LfgBIEbOaiaD6wJ/jqvwcEp/zXNsIdXrU=; b=hTr+k5rQwS+Kwr6Vnv0cS1Nzlm3CzxAdWvCXtr7H4uu9lrHd1sTWchfKseDjJ7a83p PBzVCCmqtdPBcBt+kgVKPr/Zfodhicy+EGm/GmgS+vfYs+KRBbFdZx+liJapzC/46kCs pwgnuBJojMD1uzdyjP4ma5HmlL7JLLUsd0K74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=tEftELJDCAY0zyfTtpdoY+L3BZbbzt+8BuLhgAWai4cP+lOO3pVq3XWA81kRaUOucM zVcUewixTOysIqXbI8e0gAJmzLZT2AkPvpI2mQCJ9AguCEROy2D6ZOQJUs98v7VQz13r W30STdqj2PR9wWiDmO1FSoykzXO2u5c5cJvEk= Received: by 10.223.96.67 with SMTP id g3mr14785108fan.19.1297366667028; Thu, 10 Feb 2011 11:37:47 -0800 (PST) Received: from [10.1.1.5] ([121.98.190.33]) by mx.google.com with ESMTPS id y3sm233587fai.14.2011.02.10.11.37.41 (version=SSLv3 cipher=OTHER); Thu, 10 Feb 2011 11:37:44 -0800 (PST) Message-ID: <4D543E7E.3010906@gmail.com> Date: Fri, 11 Feb 2011 08:37:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: v6ops@ietf.org References: <4D5336F8.9080506@gmail.com> <20110210185606.GA14485@srv03.cluenet.de> In-Reply-To: <20110210185606.GA14485@srv03.cluenet.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Carrier Grade NAT => ISP-operated NAT44 (NAT444 scenario) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 19:37:36 -0000 On 2011-02-11 07:56, Daniel Roesen wrote: > On Thu, Feb 10, 2011 at 01:53:12PM +1300, Brian E Carpenter wrote: >> More comments are welcome, but please please please choose a new >> subject header for each topic; if you don't do this and we get >> another few hundred messages under the same subject, the chances that >> your point will be noticed are very small. > > I would suggest replacing all references to the marketing term "Carrier > Grade NAT" with "ISP-operated NAT44", depending on the context > ammended by "(NAT444 scenario)" to more clearly specify the setting. The BEHAVE WG just decided to stick to "CGN". Actually your phrase is a good one, but I guess I have to follow the BEHAVE party line. Brian From brian.e.carpenter@gmail.com Thu Feb 10 11:55:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D73923A67BD for ; Thu, 10 Feb 2011 11:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.217 X-Spam-Level: X-Spam-Status: No, score=-102.217 tagged_above=-999 required=5 tests=[AWL=-0.892, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffsKUiQ8o7kd for ; Thu, 10 Feb 2011 11:55:15 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id D528F3A67B3 for ; Thu, 10 Feb 2011 11:55:14 -0800 (PST) Received: by fxm9 with SMTP id 9so2121272fxm.31 for ; Thu, 10 Feb 2011 11:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o2HuCunFuiOj3e2i1sGIfWJaozvxmuGnCb47oT2Aisc=; b=FnYu/Yxw+jJ7fdJjY7iRgUwSWFTXYe5pLDtXXBvTEJ6WjvTWjHVl3cjbhFM7nmWJS1 BtFXtDckFJH8noWF/jOrkSDolfl7m75MuCpxgNmiD+SEJvrTMHlpInu7eTKvHWrRb3gL OgIwvc1M+mRxCdzk8D6bbnzbqnvpEkNeTGGx0= 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=BzdqVVx8rDiHbR70lbwnvIYdjWHWPLBGozzVEVFkxGpm4q4xGj8bqsLwOw0ouUGPWu Ydka7CCpHDD+wuzabKYimOlXQPdNRQQ+89OvrIRMJaObxs9Yv7tLVP+LFVLDQEUAYVJY OPmUQSfOq2oMA/031MW3tR1dHXzY+UstIMt7k= Received: by 10.223.97.8 with SMTP id j8mr11959602fan.141.1297366944193; Thu, 10 Feb 2011 11:42:24 -0800 (PST) Received: from [10.1.1.5] ([121.98.190.33]) by mx.google.com with ESMTPS id n3sm232982fax.7.2011.02.10.11.42.19 (version=SSLv3 cipher=OTHER); Thu, 10 Feb 2011 11:42:23 -0800 (PST) Message-ID: <4D543F94.8090505@gmail.com> Date: Fri, 11 Feb 2011 08:42:12 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pekka Savola References: <4D5336F8.9080506@gmail.com> <61F0E9D3-19D1-4F26-A167-022FBB618834@apple.com> <20110210072104.GA5220@srv03.cluenet.de> <09746C7E-1BB8-4DAD-9FE6-9FC05FE9AE87@apple.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] 6to4 reliability check X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 19:55:15 -0000 Pekka, Do the words I have in the draft cover it adequately? If not, please send suggested text. " Unless the answer to all these questions is 'yes', subscribers will be no worse off, and possibly better off, if the route to 192.88.99.1 is blocked and generates 'destination unreachable'. At least one host implementation (Windows XP) starts with a 'ping' to the anycast address, so will quickly learn that 6to4 is not available [Savola]." (As James implied, I'm not very interested in adding suggestions for improvements to 6to4 code at this point in history.) Regards Brian On 2011-02-11 07:22, Pekka Savola wrote: > On Thu, 10 Feb 2011, james woodyatt wrote: >>> This is suboptimal... >> >> I agree. I'm not describing what should be done in the future, but >> rather what has already been done and shipped in large numbers around >> the world. We're talking about a terrain feature, remember? > > It is good to hear what some implementations have done. Even better > would be hearing about the side effects. > > The more robust check I mentioned has been deployed and is being run by > (dozens of?) millions of Windows boxes daily for at least 5+ years now. > > It's causing some load on the relays, but otherwise I suppose it works OK. > From v6ops@daork.net Thu Feb 10 14:00:35 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C74D3A6A14 for ; Thu, 10 Feb 2011 14:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtCCplUB6Np7 for ; Thu, 10 Feb 2011 14:00:34 -0800 (PST) Received: from unobtainium.braintrust.co.nz (unobtainium.braintrust.co.nz [123.100.101.131]) by core3.amsl.com (Postfix) with ESMTP id CD0953A67AE for ; Thu, 10 Feb 2011 14:00:33 -0800 (PST) Received: from [192.168.0.21] (unknown [121.98.191.176]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id CD31E27541 for ; Fri, 11 Feb 2011 11:00:45 +1300 (NZDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Nathan Ward In-Reply-To: Date: Fri, 11 Feb 2011 11:00:45 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D5336F8.9080506@gmail.com> <61F0E9D3-19D1-4F26-A167-022FBB618834@apple.com> <20110210072104.GA5220@srv03.cluenet.de> To: IPv6 Operations X-Mailer: Apple Mail (2.1082) Subject: Re: [v6ops] 6to4 reliability check X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 22:00:35 -0000 On 11/02/2011, at 5:55 AM, Pekka Savola wrote: > This is suboptimal compared to the implementation I described and can = be read about e.g. from http://netcore.fi/pekkas/6to4.pdf because the = check you describe only succeeds if the relay is configured with = 2002:c058:6301:: or supports subnet-router anycast address. I think both these methods are suboptimal as they don't test whether the = relay is actually usable to reach the IPv6 network, though the Windows = method of selecting a relay's non-anycast IPv4 address is interesting, = and should perhaps be looked in to further. I posted a mail to this list yesterday that seems to have not escaped my = mail client. Anyway, about 2 years ago I wrote up how we might do this = better, in a way that is easy to deploy now, doesn't require support of = existing relays (special addresses, etc), tests the ability of a relay = to forward traffic to the IPv6 network, and tests for more things than = simply "is reachable". It does, as with all these solutions, require support from "client" = implementations - however like I say, no relay support is required so is = (in my opinion) much easier to have deployed and usable rapidly. Folks didn't seem interested at the time and I had other commitments so = didn't pursue this - maybe it's time to kick it off again? http://tools.ietf.org/agenda/74/slides/v6ops-11.pdf http://tools.ietf.org/html/draft-nward-6to4-qualification-00 -- Nathan Ward= From narten@us.ibm.com Thu Feb 10 17:34:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8B143A672F for ; Thu, 10 Feb 2011 17:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eciCNLypNXBH for ; Thu, 10 Feb 2011 17:34:16 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 21A013A6971 for ; Thu, 10 Feb 2011 17:34:16 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1B18owt013009 for ; Thu, 10 Feb 2011 20:09:05 -0500 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 8AD0F4DE8026 for ; Thu, 10 Feb 2011 20:33:25 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1B1YHkH2584682 for ; Thu, 10 Feb 2011 20:34:17 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p1B1YHbB013507 for ; Thu, 10 Feb 2011 20:34:17 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-76-142-130.mts.ibm.com [9.76.142.130]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p1B1YGD2013478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Feb 2011 20:34:16 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p1B1YEW6009144; Thu, 10 Feb 2011 20:34:14 -0500 Message-Id: <201102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com> To: v6ops@ietf.org, Matt Crawford In-reply-to: <20110208074710.GB18776@srv03.cluenet.de> References: <20110203224351.GA27225@srv03.cluenet.de> <201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com> <20110207211826.GB13323@srv03.cluenet.de> <4ABF4068-018A-4D24-93A7-B1069AC99333@fnal.gov> <20110208074710.GB18776@srv03.cluenet.de> Comments: In-reply-to Daniel Roesen message dated "Tue, 08 Feb 2011 08:47:10 +0100." Date: Thu, 10 Feb 2011 20:34:14 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 01:34:17 -0000 What RFC 2464 says is: 2. Maximum Transmission Unit The default MTU size for IPv6 [IPV6] packets on an Ethernet is 1500 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of each node. If a Router Advertisement received on an Ethernet interface has an MTU option specifying an MTU larger than 1500, or larger than a manually configured value, that MTU option may be logged to system management but must be otherwise ignored. To me, that pretty clearly means you can't bump the MTU above 1500 via an RA. This was almost certainly done because 1500 *is* the MTU of Ethernets. Rightly or wrongly, Jumbo frames have never been standardized. Indeed, the IETF and the IEEE had an exchange of some sort over this very issue, and the IETF decided not to bless or standardize jumbo frames. I'm pretty sure there are some documents or statements about that, but can't find them right off. Thomas From jbates@brightok.net Thu Feb 10 18:39:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AF4D3A67F4 for ; Thu, 10 Feb 2011 18:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9grmHBk-CA4S for ; Thu, 10 Feb 2011 18:39:21 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 43EBF3A676A for ; Thu, 10 Feb 2011 18:39:21 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p1B2dXkT017186; Thu, 10 Feb 2011 20:39:33 -0600 (CST) Message-ID: <4D54A15D.4050700@brightok.net> Date: Thu, 10 Feb 2011 20:39:25 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Thomas Narten References: <20110203224351.GA27225@srv03.cluenet.de> <201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com> <20110207211826.GB13323@srv03.cluenet.de> <4ABF4068-018A-4D24-93A7-B1069AC99333@fnal.gov> <20110208074710.GB18776@srv03.cluenet.de> <201102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com> In-Reply-To: <201102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 02:39:22 -0000 On 2/10/2011 7:34 PM, Thomas Narten wrote: > This was almost certainly done because 1500 *is* the MTU of Ethernets. > > Rightly or wrongly, Jumbo frames have never been standardized. > > Indeed, the IETF and the IEEE had an exchange of some sort over this > very issue, and the IETF decided not to bless or standardize jumbo > frames. I'm pretty sure there are some documents or statements about > that, but can't find them right off. To not standardize and to purposely attempt to block and disrupt current practices are two different things. Also, it is MORE accurate to say that 1500 is the MTU of IP over Ethernet. I don't have a single Ethernet which communicates at 1500 bytes. Jack From gbonser@seven.com Thu Feb 10 21:17:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C4893A6857 for ; Thu, 10 Feb 2011 21:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ee2w1dnpVWP8 for ; Thu, 10 Feb 2011 21:17:08 -0800 (PST) Received: from wex.seven.com (wex.seven.com [208.87.204.25]) by core3.amsl.com (Postfix) with ESMTP id 0BD6B3A6848 for ; Thu, 10 Feb 2011 21:17:07 -0800 (PST) Received: from wex.seven.com ([10.1.16.28]) by wex.seven.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Feb 2011 21:17:21 -0800 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, 10 Feb 2011 21:17:20 -0800 Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13A23@RWC-EX1.corp.seven.com> In-Reply-To: <4D54A15D.4050700@brightok.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvJlPJ66Qr/IXhISDCtSDcWCiMqLwAFKhZQ References: <20110203224351.GA27225@srv03.cluenet.de> <201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com> <20110207211826.GB13323@srv03.cluenet.de> <4ABF4068-018A-4D24-93A7-B1069AC99333@fnal.gov> <20110208074710.GB18776@srv03.cluenet.de><201102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com> <4D54A15D.4050700@brightok.net> From: "George Bonser" To: "Jack Bates" , "Thomas Narten" X-OriginalArrivalTime: 11 Feb 2011 05:17:21.0174 (UTC) FILETIME=[F5911360:01CBC9AA] Cc: v6ops@ietf.org, Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 05:17:09 -0000 >=20 > To not standardize and to purposely attempt to block and disrupt > current > practices are two different things. Also, it is MORE accurate to say > that 1500 is the MTU of IP over Ethernet. I don't have a single > Ethernet > which communicates at 1500 bytes. >=20 >=20 > Jack We run everything internally at 9000 MTU. Modern PMTUD as is deployed these days by default on Windows and Solaris and which you can turn on with a sysctl with Linux works really well. The MTU 9000 makes a huge difference, particularly if you have any NAS or are doing logging over the network. One of our collocation providers recently changed their peering switch to support jumbos. That doesn't mean peers need to use 9000, just means they can if they wish, but the switch will support frames that large. All of our MetroE connections save one are "jumbo clean". But it doesn't break anything out on the internet, we send a SYN and when the other end replies, they have their MSS which is the maximum segment size so we won't try to send a packet larger than that no matter what the MTU is set to. And the obligatory links to the usual documents: http://staff.psc.edu/mathis/MTU/ http://63.196.71.246/~phil/jumbo.html http://staff.psc.edu/rreddy/networking/mtu.html From gbonser@seven.com Thu Feb 10 21:24:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01203A687D for ; Thu, 10 Feb 2011 21:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM6cAtWf62xR for ; Thu, 10 Feb 2011 21:23:59 -0800 (PST) Received: from wex.seven.com (wex.seven.com [208.87.204.25]) by core3.amsl.com (Postfix) with ESMTP id 7EDB03A6848 for ; Thu, 10 Feb 2011 21:23:59 -0800 (PST) Received: from wex.seven.com ([10.1.16.28]) by wex.seven.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Feb 2011 21:24:13 -0800 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, 10 Feb 2011 21:24:11 -0800 Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13A24@RWC-EX1.corp.seven.com> In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13A23@RWC-EX1.corp.seven.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvJlPJ66Qr/IXhISDCtSDcWCiMqLwAFKhZQAACTbKA= References: <20110203224351.GA27225@srv03.cluenet.de> <201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com> <20110207211826.GB13323@srv03.cluenet.de> <4ABF4068-018A-4D24-93A7-B1069AC99333@fnal.gov> <20110208074710.GB18776@srv03.cluenet.de><201102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC13A23@RWC-EX1.corp.seven.com> From: "George Bonser" To: "George Bonser" , "Jack Bates" , "Thomas Narten" X-OriginalArrivalTime: 11 Feb 2011 05:24:13.0518 (UTC) FILETIME=[EB57C6E0:01CBC9AB] Cc: v6ops@ietf.org, Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 05:24:00 -0000 Sorry, folks, I mistook this mailbox for the ipv6-ops mailbox. Sorry to bother you. > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of George Bonser > Sent: Thursday, February 10, 2011 9:17 PM > To: Jack Bates; Thomas Narten > Cc: v6ops@ietf.org; Matt Crawford > Subject: Re: [v6ops] RFC 2464 - MTU >1500 >=20 > > > > To not standardize and to purposely attempt to block and disrupt > > current > > practices are two different things. Also, it is MORE accurate to say > > that 1500 is the MTU of IP over Ethernet. I don't have a single > > Ethernet > > which communicates at 1500 bytes. > > > > > > Jack >=20 > We run everything internally at 9000 MTU. Modern PMTUD as is deployed > these days by default on Windows and Solaris and which you can turn on > with a sysctl with Linux works really well. The MTU 9000 makes a huge > difference, particularly if you have any NAS or are doing logging over > the network. >=20 > One of our collocation providers recently changed their peering switch > to support jumbos. That doesn't mean peers need to use 9000, just > means > they can if they wish, but the switch will support frames that large. > All of our MetroE connections save one are "jumbo clean". But it > doesn't break anything out on the internet, we send a SYN and when the > other end replies, they have their MSS which is the maximum segment > size > so we won't try to send a packet larger than that no matter what the > MTU > is set to. >=20 > And the obligatory links to the usual documents: >=20 > http://staff.psc.edu/mathis/MTU/ > http://63.196.71.246/~phil/jumbo.html > http://staff.psc.edu/rreddy/networking/mtu.html >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From pekkas@netcore.fi Thu Feb 10 22:42:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4D5E3A682C for ; Thu, 10 Feb 2011 22:42:10 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KW8N2j7eKtaF for ; Thu, 10 Feb 2011 22:42:04 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 067573A6B08 for ; Thu, 10 Feb 2011 22:41:56 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p1B6fsOi014662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Feb 2011 08:41:54 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p1B6frP1014658; Fri, 11 Feb 2011 08:41:53 +0200 Date: Fri, 11 Feb 2011 08:41:53 +0200 (EET) From: Pekka Savola To: Brian E Carpenter In-Reply-To: <4D543F94.8090505@gmail.com> Message-ID: References: <4D5336F8.9080506@gmail.com> <61F0E9D3-19D1-4F26-A167-022FBB618834@apple.com> <20110210072104.GA5220@srv03.cluenet.de> <09746C7E-1BB8-4DAD-9FE6-9FC05FE9AE87@apple.com> <4D543F94.8090505@gmail.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.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: IPv6 Operations Subject: Re: [v6ops] 6to4 reliability check X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 06:42:11 -0000 On Fri, 11 Feb 2011, Brian E Carpenter wrote: > " Unless the answer to all these questions is 'yes', subscribers will > be no worse off, and possibly better off, if the route to 192.88.99.1 > is blocked and generates 'destination unreachable'. At least one > host implementation (Windows XP) starts with a 'ping' to the anycast > address, so will quickly learn that 6to4 is not available [Savola]." I do not know if an (IPv4) destination unreachable will propagate to the application (or the stack). Windows uses the method as a qualification procedure (if it doesn't work, the 6to4 relay is not used) and as such it won't get reported to the applications in such a manner that e.g. ICMPv6 error would be or how you probably hope that ICMPv4 would be. So, I would suggest the following caveat to the former (unless we get info on how implementations react -- preferable), and more precise on the methodology: Unless the answer to all these questions is 'yes', subscribers will be no worse off, and possibly better off, if the route to 192.88.99.1 is blocked and generates an IPv4 'destination unreachable'. There is little operational experience with this, however. Some implementations also perform some form of 6to4 relay qualification. For example, a host implementation (Windows) tests the protocol-41 reachability by sending an ICMPv6 echo request with Hop Limit=1 to the relay, expecting a response or Hop Limit exceeded error back. Lack of any response indicates that the 6to4 relay does not work and it is turned off [Savola]. -- 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 nick@inex.ie Fri Feb 11 02:35:18 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17903A6A07 for ; Fri, 11 Feb 2011 02:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smt9e1MUv4ak for ; Fri, 11 Feb 2011 02:35:17 -0800 (PST) Received: from mail.acquirer.com (unknown [IPv6:2001:1bb8:2004:150::2]) by core3.amsl.com (Postfix) with ESMTP id CEEFB3A69DD for ; Fri, 11 Feb 2011 02:35:16 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.internal.acquirer.com (cupcake.internal.acquirer.com [10.228.100.105]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.3) with ESMTP id p1BAZNgt076928 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 11 Feb 2011 10:35:23 GMT (envelope-from nick@inex.ie) Message-ID: <4D5510EB.5030809@inex.ie> Date: Fri, 11 Feb 2011 10:35:23 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10pre) Gecko/20110114 Thunderbird/3.3a2 MIME-Version: 1.0 To: Brian E Carpenter References: <4D5336F8.9080506@gmail.com> <20110210185606.GA14485@srv03.cluenet.de> <4D543E7E.3010906@gmail.com> In-Reply-To: <4D543E7E.3010906@gmail.com> 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: v6ops@ietf.org Subject: Re: [v6ops] Carrier Grade NAT => ISP-operated NAT44 (NAT444 scenario) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 10:35:18 -0000 On 10/02/2011 19:37, Brian E Carpenter wrote: > The BEHAVE WG just decided to stick to "CGN". Actually your phrase is a > good one, but I guess I have to follow the BEHAVE party line. There is a long-term problem here: because "Carrier Grade NAT" is a marketing term rather than a technical term which conveys a specific meaning, its meaning will degrade over time to whatever a particular vendor is attempting to sell. I'd like to second Daniel's suggestion of "ISP-Operated NAT44", because it is a specific and unambiguous technical term, which will still mean the same thing in 10 or 20 years time. Nick From jason_livingood@cable.comcast.com Fri Feb 11 03:17:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49F1C3A696E for ; Fri, 11 Feb 2011 03:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.734 X-Spam-Level: X-Spam-Status: No, score=-101.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15hiRSY4ngSe for ; Fri, 11 Feb 2011 03:17:49 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 5877C3A694F for ; Fri, 11 Feb 2011 03:17:49 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.25463116; Fri, 11 Feb 2011 04:29:18 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Fri, 11 Feb 2011 06:17:58 -0500 From: "Livingood, Jason" To: Nick Hilliard , Brian E Carpenter Thread-Topic: [v6ops] Carrier Grade NAT => ISP-operated NAT44 (NAT444 scenario) Thread-Index: AQHLyd1VL8Bpx4vBG0eqrqyHqQ+IhQ== Date: Fri, 11 Feb 2011 11:17:57 +0000 Message-ID: In-Reply-To: <4D5510EB.5030809@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.12] Content-Type: multipart/alternative; boundary="_000_C97A843C18304jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Carrier Grade NAT => ISP-operated NAT44 (NAT444 scenario) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 11:17:50 -0000 --_000_C97A843C18304jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 10/02/2011 19:37, Brian E Carpenter wrote: The BEHAVE WG just decided to stick to "CGN". Actually your phrase is a good one, but I guess I have to follow the BEHAVE party line. There is a long-term problem here: because "Carrier Grade NAT" is a marketing term rather than a technical term which conveys a specific meaning, its meaning will degrade over time to whatever a particular vendor is attempting to sell. I'd like to second Daniel's suggestion of "ISP-Operated NAT44", because it is a specific and unambiguous technical term, which will still mean the same thing in 10 or 20 years time. Or Network-Based NAT (NBN), or some variation thereof, since the operator o= f the NAT may or may not be an ISP. Think enterprise, academic, or other la= rge network=85 Also, there can be some question of what "Carrier Grade" really means. It s= ounds vaguely more scalable/available I suppose. In my experience, carrier = grade mainly means it costs more. ;-) Jason --_000_C97A843C18304jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <71364D317D2D6F4D9AF30EB05217FE22@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
On 10/02/2011 19:37, Brian E Carpenter wrote:
The BEHAVE WG just decided to stick to "CGN". Actually your = phrase is a
good one, but I guess I have to follow the BEHAVE party line.

There is a long-term problem here: because "Carrier Grade NAT&quo= t; is a
marketing term rather than a technical term which conveys a specific <= /div>
meaning, its meaning will degrade over time to whatever a particular v= endor
is attempting to sell.

I'd like to second Daniel's suggestion of "ISP-Operated NAT44&quo= t;, because it
is a specific and unambiguous technical term, which will still mean th= e
same thing in 10 or 20 years time.

Or Network-Based NAT (NBN), or some variation thereof, since the opera= tor of the NAT may or may not be an ISP. Think enterprise, academic, or oth= er large network=85

Also, there can be some question of what "Carrier Grade" rea= lly means. It sounds vaguely more scalable/available I suppose. In my exper= ience, carrier grade mainly means it costs more. ;-)

Jason
--_000_C97A843C18304jasonlivingoodcablecomcastcom_-- From nick@inex.ie Fri Feb 11 03:19:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69C6E3A696F for ; Fri, 11 Feb 2011 03:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktgD3WL48yFJ for ; Fri, 11 Feb 2011 03:19:41 -0800 (PST) Received: from mail.acquirer.com (unknown [IPv6:2001:1bb8:2004:150::2]) by core3.amsl.com (Postfix) with ESMTP id 382033A694F for ; Fri, 11 Feb 2011 03:19:40 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.internal.acquirer.com (cupcake.internal.acquirer.com [10.228.100.105]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.3) with ESMTP id p1BBJij9054976 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 11 Feb 2011 11:19:44 GMT (envelope-from nick@inex.ie) Message-ID: <4D551B50.2000309@inex.ie> Date: Fri, 11 Feb 2011 11:19:44 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10pre) Gecko/20110114 Thunderbird/3.3a2 MIME-Version: 1.0 To: "Livingood, Jason" References: In-Reply-To: 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: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Carrier Grade NAT => ISP-operated NAT44 (NAT444 scenario) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 11:19:42 -0000 On 11/02/2011 11:17, Livingood, Jason wrote: > Also, there can be some question of what "Carrier Grade" really means. It > sounds vaguely more scalable/available I suppose. In my experience, carrier > grade mainly means it costs more. ;-) Using the name "Carrier Grade" is putting lipstick on a pig. Nick From jbates@brightok.net Fri Feb 11 06:33:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ACF13A6860 for ; Fri, 11 Feb 2011 06:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0eaY31Hbofb for ; Fri, 11 Feb 2011 06:33:01 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id C5A743A685A for ; Fri, 11 Feb 2011 06:33:01 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p1BEXDC5011669; Fri, 11 Feb 2011 08:33:14 -0600 (CST) Message-ID: <4D5548A6.1040709@brightok.net> Date: Fri, 11 Feb 2011 08:33:10 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Livingood, Jason" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Carrier Grade NAT => ISP-operated NAT44 (NAT444 scenario) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 14:33:02 -0000 On 2/11/2011 5:17 AM, Livingood, Jason wrote: > Also, there can be some question of what "Carrier Grade" really means. > It sounds vaguely more scalable/available I suppose. In my experience, > carrier grade mainly means it costs more. ;-) I had shifted to the more generic LSN, which is more appropriate than CGN and is still vague enough to deal with ds-lite and NAT444. Jack From remi.despres@free.fr Fri Feb 11 06:54:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55BE3A694F for ; Fri, 11 Feb 2011 06:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.192 X-Spam-Level: X-Spam-Status: No, score=-1.192 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38W54Otj3GrE for ; Fri, 11 Feb 2011 06:54:06 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by core3.amsl.com (Postfix) with ESMTP id 138403A6999 for ; Fri, 11 Feb 2011 06:54:06 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id 3AF397000086; Fri, 11 Feb 2011 15:54:20 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id EB1D67000085; Fri, 11 Feb 2011 15:54:19 +0100 (CET) X-SFR-UUID: 20110211145419963.EB1D67000085@msfrf2412.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 11 Feb 2011 15:54:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <225247E2-3C68-435B-A376-97125350CEA8@free.fr> References: <4D5336F8.9080506@gmail.com> <61F0E9D3-19D1-4F26-A167-022FBB618834@apple.com> To: Pekka Savola X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] 6to4 advisory draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 14:54:06 -0000 Le 10 f=E9vr. 2011 =E0 07:20, Pekka Savola a =E9crit : > On Wed, 9 Feb 2011, james woodyatt wrote: >> I recommend adding text to this draft recommending that well-managed = 6to4 relays be capable of responding to ICMPv6 echo requests = encapsulated in IPv4 protocol 41. >=20 > Which IPv6 address should the relay be responding pings at? >=20 > This was actually a topic of a draft some 8 years ago but didn't go = anywhere. >=20 > Just send the echo request with TTL=3D1 like Microsoft implementation = does, and whether you receive a reply -- TTL exceeded or a response -- = is enough. >=20 +1 in favor of recommending this host behavior: it only depends on what = every relay must do. Regards, RD From remi.despres@free.fr Fri Feb 11 06:58:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A5F3A69D2 for ; Fri, 11 Feb 2011 06:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwvqnneV8Jx1 for ; Fri, 11 Feb 2011 06:58:03 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by core3.amsl.com (Postfix) with ESMTP id E27123A694F for ; Fri, 11 Feb 2011 06:58:02 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id AB1367000089; Fri, 11 Feb 2011 15:58:17 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id 83823700008B; Fri, 11 Feb 2011 15:58:17 +0100 (CET) X-SFR-UUID: 20110211145817538.83823700008B@msfrf2412.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20110210185606.GA14485@srv03.cluenet.de> Date: Fri, 11 Feb 2011 15:58:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <57DBD27E-E4B6-4E72-9EB1-59759628453E@free.fr> References: <4D5336F8.9080506@gmail.com> <20110210185606.GA14485@srv03.cluenet.de> To: v6ops v6ops X-Mailer: Apple Mail (2.1082) Cc: Daniel Roesen Subject: Re: [v6ops] Carrier Grade NAT => ISP-operated NAT44 (NAT444 scenario) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 14:58:04 -0000 Le 10 f=E9vr. 2011 =E0 19:56, Daniel Roesen a =E9crit : > On Thu, Feb 10, 2011 at 01:53:12PM +1300, Brian E Carpenter wrote: >> More comments are welcome, but please please please choose a new >> subject header for each topic; if you don't do this and we get >> another few hundred messages under the same subject, the chances that >> your point will be noticed are very small. >=20 > I would suggest replacing all references to the marketing term = "Carrier > Grade NAT" with "ISP-operated NAT44", depending on the context > ammended by "(NAT444 scenario)" to more clearly specify the setting. +1 RD >=20 > Best regards, > Daniel >=20 > --=20 > CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From remi.despres@free.fr Fri Feb 11 07:49:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FC3D3A6974 for ; Fri, 11 Feb 2011 07:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.943 X-Spam-Level: X-Spam-Status: No, score=-0.943 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cmQzQ9tazyK for ; Fri, 11 Feb 2011 07:49:37 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by core3.amsl.com (Postfix) with ESMTP id 3B4BA3A68D4 for ; Fri, 11 Feb 2011 07:49:37 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2202.sfr.fr (SMTP Server) with ESMTP id 8080E700008A; Fri, 11 Feb 2011 16:49:51 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2202.sfr.fr (SMTP Server) with ESMTP id 1CB927000082; Fri, 11 Feb 2011 16:49:51 +0100 (CET) X-SFR-UUID: 20110211154951117.1CB927000082@msfrf2202.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D543E7E.3010906@gmail.com> Date: Fri, 11 Feb 2011 16:49:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <13349FC5-5628-4889-878C-31A5FA910DF3@free.fr> References: <4D5336F8.9080506@gmail.com> <20110210185606.GA14485@srv03.cluenet.de> <4D543E7E.3010906@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] Carrier Grade NAT => ISP-operated NAT44 (NAT444 scenario) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 15:49:38 -0000 Le 10 f=E9vr. 2011 =E0 20:37, Brian E Carpenter a =E9crit : > On 2011-02-11 07:56, Daniel Roesen wrote: >> On Thu, Feb 10, 2011 at 01:53:12PM +1300, Brian E Carpenter wrote: >>> More comments are welcome, but please please please choose a new >>> subject header for each topic; if you don't do this and we get >>> another few hundred messages under the same subject, the chances = that >>> your point will be noticed are very small. >>=20 >> I would suggest replacing all references to the marketing term = "Carrier >> Grade NAT" with "ISP-operated NAT44", depending on the context >> ammended by "(NAT444 scenario)" to more clearly specify the setting. >=20 > The BEHAVE WG just decided to stick to "CGN". Actually your phrase is = a > good one, but I guess I have to follow the BEHAVE party line. >=20 Yes, where an abbreviation is used, "CGN" is the choice.=20 Where a more explicit designation is used "ISP-operated NAT44" is IMHO = much better than "Carrier-grade NAT". Regards, RD > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From crawdad@fnal.gov Fri Feb 11 07:40:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17DA83A69B2 for ; Fri, 11 Feb 2011 07:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1wfNAPjc2Jh for ; Fri, 11 Feb 2011 07:40:40 -0800 (PST) Received: from mailgw1.fnal.gov (mailgw1.fnal.gov [131.225.111.11]) by core3.amsl.com (Postfix) with ESMTP id 5917F3A6983 for ; Fri, 11 Feb 2011 07:40:40 -0800 (PST) Received: from mailav1.fnal.gov (mailav1.fnal.gov [131.225.111.18]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with SMTP id <0LGG0087TLVF16@mailgw1.fnal.gov> for v6ops@ietf.org; Fri, 11 Feb 2011 09:39:42 -0600 (CST) Received: from mailgw1.fnal.gov ([131.225.111.11]) by mailav1.fnal.gov (SAVSMTP 3.1.7.47) with SMTP id M2011021109400611934 for ; Fri, 11 Feb 2011 09:40:06 -0600 Received: from conversion-daemon.mailgw1.fnal.gov by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) id <0LGG00701LWSUM@mailgw1.fnal.gov> (original mail from crawdad@fnal.gov) for v6ops@ietf.org; Fri, 11 Feb 2011 09:39:42 -0600 (CST) Received: from dhcp-131-225-94-174.dhcp.fnal.gov (dhcp-131-225-94-174.dhcp.fnal.gov [131.225.94.174]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with ESMTPSA id <0LGG006K6M65T0@mailgw1.fnal.gov> for v6ops@ietf.org; Fri, 11 Feb 2011 09:39:42 -0600 (CST) Date: Fri, 11 Feb 2011 09:40:05 -0600 From: Matt Crawford In-reply-to: <4D54A15D.4050700@brightok.net> To: v6ops@ietf.org Message-id: <8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> MIME-version: 1.0 X-Mailer: Apple Mail (2.1082) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <20110203224351.GA27225@srv03.cluenet.de> <201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com> <20110207211826.GB13323@srv03.cluenet.de> <4ABF4068-018A-4D24-93A7-B1069AC99333@fnal.gov> <20110208074710.GB18776@srv03.cluenet.de> <201102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com> <4D54A15D.4050700@brightok.net> X-Mailman-Approved-At: Fri, 11 Feb 2011 08:01:45 -0800 Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 15:40:41 -0000 The last internet-draft for V6 over Ethernet predates the proposal of gigabit ethernet, and the publication of RFC2464 predates the ratification of IEEE 802.3ab. I believe Jumbo Frames came after the latter. The right thing would seem to be one of: A. Let it stand, and demand use of DHCPv6 (or manual configuration) to set an MTU > 1500. B. Supersede 2464 with a new specification C. Update 2464 with an RFC on MTU alone. From Fred.L.Templin@boeing.com Fri Feb 11 08:18:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECDF73A69B4 for ; Fri, 11 Feb 2011 08:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWthh9kfm1CY for ; Fri, 11 Feb 2011 08:18:22 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 2F0F33A68C0 for ; Fri, 11 Feb 2011 08:18:22 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1BGIZM2016934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Feb 2011 08:18:36 -0800 (PST) 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 p1BGIZXY004814; Fri, 11 Feb 2011 08:18:35 -0800 (PST) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1BGIYtK004801 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 11 Feb 2011 08:18:35 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Fri, 11 Feb 2011 08:18:34 -0800 From: "Templin, Fred L" To: Matt Crawford , "v6ops@ietf.org" Date: Fri, 11 Feb 2011 08:18:34 -0800 Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvKBQujVCs7oCSVQa+BOUmiex1FAgAAUibA Message-ID: References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichlid .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><201 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok.net> <8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> In-Reply-To: <8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> 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] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 16:18:23 -0000 Hi Matt,=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Matt Crawford > Sent: Friday, February 11, 2011 7:40 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] RFC 2464 - MTU >1500 >=20 > The last internet-draft for V6 over Ethernet predates the=20 > proposal of gigabit ethernet, and the publication of RFC2464=20 > predates the ratification of IEEE 802.3ab. I believe Jumbo=20 > Frames came after the latter. >=20 > The right thing would seem to be one of: >=20 > A. Let it stand, and demand use of DHCPv6 (or manual=20 > configuration) to set an MTU > 1500. >=20 > B. Supersede 2464 with a new specification >=20 > C. Update 2464 with an RFC on MTU alone. The MTU is not necessarily the same as the Maximum Receive Unit (MRU). So for instance, if a host sets an MTU of 1500 on an Ethernet interface, but it configures a receive buffer large enough to receive unfragmented packets of up to 2K, what should it do if it receives a UDP packet larger than 1500? I say keep it - why throw away good data? But, others may have a different opinion. The point being, if there were a new document to talk about MTU it might also want to discuss MRU. Thanks - Fred fred.l.templin@boeing.com=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From fred@cisco.com Fri Feb 11 08:39:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C96C3A69CF for ; Fri, 11 Feb 2011 08:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ode5utC4fW1 for ; Fri, 11 Feb 2011 08:39:09 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9E35B3A6989 for ; Fri, 11 Feb 2011 08:39:09 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPL0VE2rRN+K/2dsb2JhbACldHOfYZs7hV0EhQGGe4My X-IronPort-AV: E=Sophos;i="4.60,455,1291593600"; d="scan'208";a="328510987" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 11 Feb 2011 16:39:24 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p1BGdJ0A006678; Fri, 11 Feb 2011 16:39:24 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Fri, 11 Feb 2011 08:39:24 -0800 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Fri, 11 Feb 2011 08:39:24 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> Date: Fri, 11 Feb 2011 08:39:09 -0800 Message-Id: References: <20110203224351.GA27225@srv03.cluenet.de> <201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com> <20110207211826.GB13323@srv03.cluenet.de> <4ABF4068-018A-4D24-93A7-B1069AC99333@fnal.gov> <20110208074710.GB18776@srv03.cluenet.de> <201102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com> <4D54A15D.4050700@brightok.net> <8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> To: Matt Crawford X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 16:39:10 -0000 On Feb 11, 2011, at 7:40 AM, Matt Crawford wrote: > The last internet-draft for V6 over Ethernet predates the proposal of = gigabit ethernet, and the publication of RFC2464 predates the = ratification of IEEE 802.3ab. I believe Jumbo Frames came after the = latter. >=20 > The right thing would seem to be one of: >=20 > A. Let it stand, and demand use of DHCPv6 (or manual configuration) to = set an MTU > 1500. >=20 > B. Supersede 2464 with a new specification >=20 > C. Update 2464 with an RFC on MTU alone. I think the right thing to do is (C), an update to 2464 and the various = RFCs that refer to a magic numbers 1500 or 1280, indicating that IPv6 = MTU *in*all*cases* follows the same rules as IPv4, which is to say that = it uses defaults appropriate to the characteristics of the link layer = and is subject to local configuration, DHCP configuration, TCP MSS = negotiation, and Path MTU. The number "1280" is important in a world = where IPv6 is primarily carried in tunnels, and 1500 is important to = Ethernets below 1 Gig. But we are in the process of making IPv6 native, = and have link layer MTUs as small as 128 without a means to link = fragments of higher layer protocols together (so the rule trying to = impose that on link layer protocols is broken) and as high as 18,000 = (Token thing).= From Fred.L.Templin@boeing.com Fri Feb 11 08:56:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7AFB3A69FF for ; Fri, 11 Feb 2011 08:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3u-0XI0RGW8s for ; Fri, 11 Feb 2011 08:56:20 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id DBF5C3A679C for ; Fri, 11 Feb 2011 08:56:19 -0800 (PST) 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 p1BGuPTq013826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Feb 2011 10:56:26 -0600 (CST) 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 p1BGuPVA022144; Fri, 11 Feb 2011 08:56:25 -0800 (PST) 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 p1BGuOUX022128 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 11 Feb 2011 08:56:25 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Fri, 11 Feb 2011 08:56:24 -0800 From: "Templin, Fred L" To: Fred Baker , Matt Crawford Date: Fri, 11 Feb 2011 08:56:24 -0800 Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvKCmnuHyET9RluT+GbsRGqk4evIAAAfHPg Message-ID: References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichlid .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><201 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> 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] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 16:56:23 -0000 Hi Fred,=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Fred Baker > Sent: Friday, February 11, 2011 8:39 AM > To: Matt Crawford > Cc: v6ops@ietf.org > Subject: Re: [v6ops] RFC 2464 - MTU >1500 >=20 >=20 > On Feb 11, 2011, at 7:40 AM, Matt Crawford wrote: >=20 > > The last internet-draft for V6 over Ethernet predates the=20 > proposal of gigabit ethernet, and the publication of RFC2464=20 > predates the ratification of IEEE 802.3ab. I believe Jumbo=20 > Frames came after the latter. > >=20 > > The right thing would seem to be one of: > >=20 > > A. Let it stand, and demand use of DHCPv6 (or manual=20 > configuration) to set an MTU > 1500. > >=20 > > B. Supersede 2464 with a new specification > >=20 > > C. Update 2464 with an RFC on MTU alone. >=20 > >=20 > I think the right thing to do is (C), an update to 2464 and=20 > the various RFCs that refer to a magic numbers 1500 or 1280,=20 > indicating that IPv6 MTU *in*all*cases* follows the same=20 > rules as IPv4, which is to say that it uses defaults=20 > appropriate to the characteristics of the link layer and is=20 > subject to local configuration, DHCP configuration, TCP MSS=20 > negotiation, and Path MTU. The number "1280" is important in=20 > a world where IPv6 is primarily carried in tunnels, Not if the tunnel has a way of figuring out how large the subnetwork can support, which might be considerably larger than 1280. Thanks - Fred fred.l.templin@boeing.com > and 1500=20 > is important to Ethernets below 1 Gig. But we are in the=20 > process of making IPv6 native, and have link layer MTUs as=20 > small as 128 without a means to link fragments of higher=20 > layer protocols together (so the rule trying to impose that=20 > on link layer protocols is broken) and as high as 18,000=20 > (Token thing). > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From fred@cisco.com Fri Feb 11 09:10:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5E43A67AE for ; Fri, 11 Feb 2011 09:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.116 X-Spam-Level: X-Spam-Status: No, score=-110.116 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KajJufKngPcj for ; Fri, 11 Feb 2011 09:10:14 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1375B3A679C for ; Fri, 11 Feb 2011 09:10:14 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEBANj7VE2rR7Hu/2dsb2JhbACXF45dc589mzeFXQSFAYZ7gzI X-IronPort-AV: E=Sophos;i="4.60,456,1291593600"; d="scan'208";a="309349749" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2011 17:10:29 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1BHAOWT021207; Fri, 11 Feb 2011 17:10:29 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Fri, 11 Feb 2011 09:10:29 -0800 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Fri, 11 Feb 2011 09:10:29 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Fri, 11 Feb 2011 09:10:14 -0800 Message-Id: <5D7635B4-E2E0-4828-AF4E-EDE521EF7FCB@cisco.com> References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichlid .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><201 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 17:10:15 -0000 On Feb 11, 2011, at 8:56 AM, Templin, Fred L wrote: > Hi Fred, > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] >> On Behalf Of Fred Baker >> Sent: Friday, February 11, 2011 8:39 AM >> To: Matt Crawford >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] RFC 2464 - MTU >1500 >> >> >> On Feb 11, 2011, at 7:40 AM, Matt Crawford wrote: >> >>> The last internet-draft for V6 over Ethernet predates the >> proposal of gigabit ethernet, and the publication of RFC2464 >> predates the ratification of IEEE 802.3ab. I believe Jumbo >> Frames came after the latter. >>> >>> The right thing would seem to be one of: >>> >>> A. Let it stand, and demand use of DHCPv6 (or manual >> configuration) to set an MTU > 1500. >>> >>> B. Supersede 2464 with a new specification >>> >>> C. Update 2464 with an RFC on MTU alone. >> >> >> >> I think the right thing to do is (C), an update to 2464 and >> the various RFCs that refer to a magic numbers 1500 or 1280, >> indicating that IPv6 MTU *in*all*cases* follows the same >> rules as IPv4, which is to say that it uses defaults >> appropriate to the characteristics of the link layer and is >> subject to local configuration, DHCP configuration, TCP MSS >> negotiation, and Path MTU. The number "1280" is important in >> a world where IPv6 is primarily carried in tunnels, > > Not if the tunnel has a way of figuring out how large > the subnetwork can support, which might be considerably > larger than 1280. Which takes you back to the previous clause... > Thanks - Fred > fred.l.templin@boeing.com > >> and 1500 >> is important to Ethernets below 1 Gig. But we are in the >> process of making IPv6 native, and have link layer MTUs as >> small as 128 without a means to link fragments of higher >> layer protocols together (so the rule trying to impose that >> on link layer protocols is broken) and as high as 18,000 >> (Token thing). >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> From Fred.L.Templin@boeing.com Fri Feb 11 09:23:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243823A67F6 for ; Fri, 11 Feb 2011 09:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.105 X-Spam-Level: X-Spam-Status: No, score=-6.105 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7L88UvvZt+5 for ; Fri, 11 Feb 2011 09:23:15 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 1179E3A67D9 for ; Fri, 11 Feb 2011 09:23:14 -0800 (PST) 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 p1BHN1ni010478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Feb 2011 09:23:01 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1BHN0hx027123; Fri, 11 Feb 2011 09:23:00 -0800 (PST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1BHN0Va027116 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 11 Feb 2011 09:23:00 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Fri, 11 Feb 2011 09:23:00 -0800 From: "Templin, Fred L" To: Fred Baker Date: Fri, 11 Feb 2011 09:23:02 -0800 Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvKDqM24sYsOqmkRRSQUxTJQAFMZgAAC/6w Message-ID: References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichli d .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><20 1 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> <5D7635B4-E2E0-4828-AF4E-EDE521EF7FCB@cisco.com> In-Reply-To: <5D7635B4-E2E0-4828-AF4E-EDE521EF7FCB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 17:23:16 -0000 Hi Fred,=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Friday, February 11, 2011 9:10 AM > To: Templin, Fred L > Cc: Matt Crawford; v6ops@ietf.org > Subject: Re: [v6ops] RFC 2464 - MTU >1500 >=20 >=20 > On Feb 11, 2011, at 8:56 AM, Templin, Fred L wrote: >=20 > > Hi Fred,=20 > >=20 > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > >> On Behalf Of Fred Baker > >> Sent: Friday, February 11, 2011 8:39 AM > >> To: Matt Crawford > >> Cc: v6ops@ietf.org > >> Subject: Re: [v6ops] RFC 2464 - MTU >1500 > >>=20 > >>=20 > >> On Feb 11, 2011, at 7:40 AM, Matt Crawford wrote: > >>=20 > >>> The last internet-draft for V6 over Ethernet predates the=20 > >> proposal of gigabit ethernet, and the publication of RFC2464=20 > >> predates the ratification of IEEE 802.3ab. I believe Jumbo=20 > >> Frames came after the latter. > >>>=20 > >>> The right thing would seem to be one of: > >>>=20 > >>> A. Let it stand, and demand use of DHCPv6 (or manual=20 > >> configuration) to set an MTU > 1500. > >>>=20 > >>> B. Supersede 2464 with a new specification > >>>=20 > >>> C. Update 2464 with an RFC on MTU alone. > >>=20 > >> > >>=20 > >> I think the right thing to do is (C), an update to 2464 and=20 > >> the various RFCs that refer to a magic numbers 1500 or 1280,=20 > >> indicating that IPv6 MTU *in*all*cases* follows the same=20 > >> rules as IPv4, which is to say that it uses defaults=20 > >> appropriate to the characteristics of the link layer and is=20 > >> subject to local configuration, DHCP configuration, TCP MSS=20 > >> negotiation, and Path MTU. The number "1280" is important in=20 > >> a world where IPv6 is primarily carried in tunnels, > >=20 > > Not if the tunnel has a way of figuring out how large > > the subnetwork can support, which might be considerably > > larger than 1280. >=20 > Which takes you back to the previous clause... But then, not all tunnels are equal when it comes to the means available at their disposal to determine the MTU. Some have no recourse but to select a "safe" static value, and 1280 is as small as they are permitted to go. RFC4213 mandates that there be a "configuration knob" for selecting static MTUs larger than 1280, but tunneling mechanisms that don't have a means of determining dynamic MTUs are taking risks when they set larger values. =20 Thanks - Fred fred.l.templin@boeing.com =20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > >> and 1500=20 > >> is important to Ethernets below 1 Gig. But we are in the=20 > >> process of making IPv6 native, and have link layer MTUs as=20 > >> small as 128 without a means to link fragments of higher=20 > >> layer protocols together (so the rule trying to impose that=20 > >> on link layer protocols is broken) and as high as 18,000=20 > >> (Token thing). > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >>=20 >=20 > = From fred@cisco.com Fri Feb 11 09:44:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A502C3A6860 for ; Fri, 11 Feb 2011 09:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.104 X-Spam-Level: X-Spam-Status: No, score=-110.104 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBrw3uP9dLMA for ; Fri, 11 Feb 2011 09:44:18 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D02C03A67AF for ; Fri, 11 Feb 2011 09:44:18 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHkDVU2rR7Ht/2dsb2JhbACldHOfU5syhV0EhQGGe4My X-IronPort-AV: E=Sophos;i="4.60,456,1291593600"; d="scan'208";a="328541480" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 11 Feb 2011 17:44:33 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1BHiTH7023971; Fri, 11 Feb 2011 17:44:33 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Fri, 11 Feb 2011 09:44:34 -0800 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Fri, 11 Feb 2011 09:44:34 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Fri, 11 Feb 2011 09:44:19 -0800 Message-Id: <4B737278-9754-4583-A639-BC8022205582@cisco.com> References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichli d .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><20 1 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> <5D7635B4-E2E0-4828-AF4E-EDE521EF7FCB@cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 17:44:19 -0000 On Feb 11, 2011, at 9:23 AM, Templin, Fred L wrote: > But then, not all tunnels are equal when it comes to the > means available at their disposal to determine the MTU. > Some have no recourse but to select a "safe" static value, > and 1280 is as small as they are permitted to go. Well, yes, and that is generally a good thing. But hosts are also told = that they can ignore any indications of a path MTU smaller than 1280. = =46rom RFC 2460: IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. IEEE 802 didn't ask us about that when they designed IEEE 802.15.4. = Link-specific fragmentation and reassembly is specifically something = that IEEE LAN technologies don't do, and all the bleating we might = produce doesn't have much effect on them. > RFC4213 mandates that there be a "configuration knob" > for selecting static MTUs larger than 1280, but tunneling > mechanisms that don't have a means of determining dynamic > MTUs are taking risks when they set larger values. =20 Tunnels must have their MTU configurable. That's a good thing. But I = don't see the "risk" in having an MTU *larger* than common traffic - a = larger MTU doesn't inhibit the traffic in any way. The only risk I see = is that traffic may or may not take advantage of it. > Thanks - Fred > fred.l.templin@boeing.com >=20 >>> Thanks - Fred >>> fred.l.templin@boeing.com >>>=20 >>>> and 1500=20 >>>> is important to Ethernets below 1 Gig. But we are in the=20 >>>> process of making IPv6 native, and have link layer MTUs as=20 >>>> small as 128 without a means to link fragments of higher=20 >>>> layer protocols together (so the rule trying to impose that=20 >>>> on link layer protocols is broken) and as high as 18,000=20 >>>> (Token thing). >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>=20 >>=20 From Fred.L.Templin@boeing.com Fri Feb 11 10:05:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0F53A6860 for ; Fri, 11 Feb 2011 10:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra0KvmHWTg2U for ; Fri, 11 Feb 2011 10:05:41 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id B10AC3A67F6 for ; Fri, 11 Feb 2011 10:05:41 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1BI5q0c024051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Feb 2011 12:05:53 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1BI5pmb014370; Fri, 11 Feb 2011 10:05:51 -0800 (PST) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1BI55w6012503 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 11 Feb 2011 10:05:49 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Fri, 11 Feb 2011 10:05:49 -0800 From: "Templin, Fred L" To: Fred Baker Date: Fri, 11 Feb 2011 10:05:49 -0800 Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvKE12HrFPVTE71Tnu7tR8RA+dI/wAART2g Message-ID: References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichli d .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><20 1 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> <5D7635B4-E2E0-4828-AF4E-EDE521EF7FCB@cisco.com> <4B737278-9754-4583-A639-BC8022205582@cisco.com> In-Reply-To: <4B737278-9754-4583-A639-BC8022205582@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 18:05:42 -0000 Hi Fred,=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Friday, February 11, 2011 9:44 AM > To: Templin, Fred L > Cc: Matt Crawford; v6ops@ietf.org > Subject: Re: [v6ops] RFC 2464 - MTU >1500 >=20 >=20 > On Feb 11, 2011, at 9:23 AM, Templin, Fred L wrote: > > But then, not all tunnels are equal when it comes to the > > means available at their disposal to determine the MTU. > > Some have no recourse but to select a "safe" static value, > > and 1280 is as small as they are permitted to go. >=20 > Well, yes, and that is generally a good thing. But hosts are=20 > also told that they can ignore any indications of a path MTU=20 > smaller than 1280. From RFC 2460: >=20 > IPv6 requires that every link in the internet have an MTU of 1280 > octets or greater. On any link that cannot convey a 1280-octet > packet in one piece, link-specific fragmentation and=20 > reassembly must > be provided at a layer below IPv6. >=20 > IEEE 802 didn't ask us about that when they designed IEEE=20 > 802.15.4. Link-specific fragmentation and reassembly is=20 > specifically something that IEEE LAN technologies don't do,=20 > and all the bleating we might produce doesn't have much=20 > effect on them. Right; links like that are challenging for some types of tunnels, but can be handled by others. I believe those sorts of links typically show up in edge networks and not so much in transit networks, however?=20 =20 > > RFC4213 mandates that there be a "configuration knob" > > for selecting static MTUs larger than 1280, but tunneling > > mechanisms that don't have a means of determining dynamic > > MTUs are taking risks when they set larger values. =20 >=20 > Tunnels must have their MTU configurable. That's a good=20 > thing. But I don't see the "risk" in having an MTU *larger*=20 > than common traffic - a larger MTU doesn't inhibit the=20 > traffic in any way. The only risk I see is that traffic may=20 > or may not take advantage of it. Tunnels over IPv4 that set larger than 1280 need to worry about IP fragmentation issues (RFC4459, RFC4963) and/or loss of ICMPv4 PTBs (RFC2923, RFC5927). Thanks - Fred fred.l.templin@boeing.com =20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>>=20 > >>>> and 1500=20 > >>>> is important to Ethernets below 1 Gig. But we are in the=20 > >>>> process of making IPv6 native, and have link layer MTUs as=20 > >>>> small as 128 without a means to link fragments of higher=20 > >>>> layer protocols together (so the rule trying to impose that=20 > >>>> on link layer protocols is broken) and as high as 18,000=20 > >>>> (Token thing). > >>>> _______________________________________________ > >>>> v6ops mailing list > >>>> v6ops@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/v6ops > >>>>=20 > >>=20 > >>=20 >=20 > = From fred@cisco.com Fri Feb 11 10:19:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7C43A6860 for ; Fri, 11 Feb 2011 10:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.394 X-Spam-Level: X-Spam-Status: No, score=-110.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdTuH5632aWJ for ; Fri, 11 Feb 2011 10:19:19 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 921FD3A67AE for ; Fri, 11 Feb 2011 10:19:19 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGMMVU2rR7H+/2dsb2JhbACldHOfUpsxhV0EhQGGe4My X-IronPort-AV: E=Sophos;i="4.60,456,1291593600"; d="scan'208";a="309379250" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2011 18:19:35 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1BIJGTo011779; Fri, 11 Feb 2011 18:19:34 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Fri, 11 Feb 2011 10:19:34 -0800 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Fri, 11 Feb 2011 10:19:34 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Fri, 11 Feb 2011 10:19:34 -0800 Message-Id: <2C989009-9999-4170-B368-678F04CFCB29@cisco.com> References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichli d .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><20 1 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> <5D7635B4-E2E0-4828-AF4E-EDE521EF7FCB@cisco.com> <4B737278-9754-4583-A639-BC8022205582@cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 18:19:20 -0000 What's your point? From Fred.L.Templin@boeing.com Fri Feb 11 11:42:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29FFE3A6A3B for ; Fri, 11 Feb 2011 11:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.397 X-Spam-Level: X-Spam-Status: No, score=-6.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBPuiNM+EMAd for ; Fri, 11 Feb 2011 11:42:08 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 5F5083A6A3A for ; Fri, 11 Feb 2011 11:42:08 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1BJgHFC013868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Feb 2011 11:42:17 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1BJgGGU010225; Fri, 11 Feb 2011 13:42:16 -0600 (CST) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1BJgGHZ010202 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 11 Feb 2011 13:42:16 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Fri, 11 Feb 2011 11:42:16 -0800 From: "Templin, Fred L" To: Fred Baker Date: Fri, 11 Feb 2011 11:42:17 -0800 Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvKGEPYJSm7Dqt2T5GoIVNeYnyR0gACEDkg Message-ID: References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichli d .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><20 1 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> <5D7635B4-E2E0-4828-AF4E-EDE521EF7FCB@cisco.com> <4B737278-9754-4583-A639-BC8022205582@cisco.com> <2C989009-9999-4170-B368-678F04CFCB29@cisco.com> In-Reply-To: <2C989009-9999-4170-B368-678F04CFCB29@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 19:42:09 -0000 > What's your point? Are you asking whether I'm trying to achieve a specific objective? Because I'm not - I'm just going with the flow of the discussion as it is evolving. That said, the discussion seems to be trending toward a consideration of what types of links we might want to run IPv6 over. Personally, I think the answer is "all of them" - but as you have noted there are links that can't do 1280 natively. For example, some links have such low data rates and/or such high BERs that time-on-the-wire would make it prohibitive to send 1280 packets all in one piece. So, we need to find some way to convey 1280 IPv6 packets over those sorts of links since IPv6 does not permit in-the-network fragmentation. So, there needs to be some segmentation/reassembly at a layer below IPv6. There are many different ways to do that, however, and it may or may not be possible to pick just one size that fits all. That's all - Fred fred.l.templin@boeing.com= From fred@cisco.com Fri Feb 11 11:53:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6713A6A51 for ; Fri, 11 Feb 2011 11:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.411 X-Spam-Level: X-Spam-Status: No, score=-110.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNG0mmmiX3Z6 for ; Fri, 11 Feb 2011 11:53:30 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9BD4A3A698E for ; Fri, 11 Feb 2011 11:53:30 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKYiVU2rR7H+/2dsb2JhbACldXOfTJsvhV0EhQGGe4My X-IronPort-AV: E=Sophos;i="4.60,457,1291593600"; d="scan'208";a="309418019" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2011 19:53:46 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1BJrgG6007612; Fri, 11 Feb 2011 19:53:46 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Fri, 11 Feb 2011 11:53:46 -0800 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Fri, 11 Feb 2011 11:53:46 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Fri, 11 Feb 2011 11:53:30 -0800 Message-Id: References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichli d .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><20 1 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> <5D7635B4-E2E0-4828-AF4E-EDE521EF7FCB@cisco.com> <4B737278-9754-4583-A639-BC8022205582@cisco.com> <2C989009-9999-4170-B368-678F04CFCB29@cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 19:53:31 -0000 On Feb 11, 2011, at 11:42 AM, Templin, Fred L wrote: > So, we need to find some way to convey 1280 IPv6 packets > over those sorts of links since IPv6 does not permit > in-the-network fragmentation. So, there needs to be some > segmentation/reassembly at a layer below IPv6. I think you would generally be told that's 6lowpan. From Fred.L.Templin@boeing.com Fri Feb 11 12:57:35 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B0723A69DA for ; Fri, 11 Feb 2011 12:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.405 X-Spam-Level: X-Spam-Status: No, score=-6.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tv7O9uHZKHFp for ; Fri, 11 Feb 2011 12:57:33 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 134143A69CA for ; Fri, 11 Feb 2011 12:57:33 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1BKvJZa021462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Feb 2011 14:57:20 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1BKvJYM018206; Fri, 11 Feb 2011 12:57:19 -0800 (PST) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1BKvJSP018195 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 11 Feb 2011 12:57:19 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Fri, 11 Feb 2011 12:57:19 -0800 From: "Templin, Fred L" To: Fred Baker Date: Fri, 11 Feb 2011 12:57:18 -0800 Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvKJYrYyaezXy90Rei0QqUVAX3E4QAB95FQ Message-ID: References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichli d .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><20 1 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> <5D7635B4-E2E0-4828-AF4E-EDE521EF7FCB@cisco.com> <4B737278-9754-4583-A639-BC8022205582@cisco.com> <2C989009-9999-4170-B368-678F04CFCB29@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" , Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 20:57:35 -0000 Hi Fred,=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Friday, February 11, 2011 11:54 AM > To: Templin, Fred L > Cc: Matt Crawford; v6ops@ietf.org > Subject: Re: [v6ops] RFC 2464 - MTU >1500 >=20 >=20 > On Feb 11, 2011, at 11:42 AM, Templin, Fred L wrote: >=20 > > So, we need to find some way to convey 1280 IPv6 packets > > over those sorts of links since IPv6 does not permit > > in-the-network fragmentation. So, there needs to be some > > segmentation/reassembly at a layer below IPv6.=20 >=20 > I think you would generally be told that's 6lowpan.=20 OK, but there are many different link types other than just IEEE 802.15.4 that don't support 1280 natively. They can either use a link-specific adaptation (many do), or they can use something that is ubiquitously available and link-agnostic. Thanks - Fred fred.l.templin@boeing.com From fred@cisco.com Fri Feb 11 13:02:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 436F33A67B3 for ; Fri, 11 Feb 2011 13:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.426 X-Spam-Level: X-Spam-Status: No, score=-110.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdntmCXpxzLz for ; Fri, 11 Feb 2011 13:02:26 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 779F43A69DA for ; Fri, 11 Feb 2011 13:02:26 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEBAFoyVU2rR7Hu/2dsb2JhbACXGI5dc59GmzKFXQSFAYZ7gzI X-IronPort-AV: E=Sophos;i="4.60,457,1291593600"; d="scan'208";a="258839927" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 11 Feb 2011 21:02:42 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1BL1n0C009475; Fri, 11 Feb 2011 21:02:41 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Fri, 11 Feb 2011 13:02:42 -0800 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Fri, 11 Feb 2011 13:02:42 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Fri, 11 Feb 2011 13:02:41 -0800 Message-Id: <614D672D-1013-4B72-9413-86C61B5B816D@cisco.com> References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichli d .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><20 1 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> <5D7635B4-E2E0-4828-AF4E-EDE521EF7FCB@cisco.com> <4B737278-9754-4583-A639-BC8022205582@cisco.com> <2C989009-9999-4170-B368-678F04CFCB29@cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 21:02:27 -0000 I frankly think it would be more sensible to accept that the MTU might = sometimes be less than 1280. On Feb 11, 2011, at 12:57 PM, Templin, Fred L wrote: > Hi Fred,=20 >=20 >> -----Original Message----- >> From: Fred Baker [mailto:fred@cisco.com]=20 >> Sent: Friday, February 11, 2011 11:54 AM >> To: Templin, Fred L >> Cc: Matt Crawford; v6ops@ietf.org >> Subject: Re: [v6ops] RFC 2464 - MTU >1500 >>=20 >>=20 >> On Feb 11, 2011, at 11:42 AM, Templin, Fred L wrote: >>=20 >>> So, we need to find some way to convey 1280 IPv6 packets >>> over those sorts of links since IPv6 does not permit >>> in-the-network fragmentation. So, there needs to be some >>> segmentation/reassembly at a layer below IPv6.=20 >>=20 >> I think you would generally be told that's 6lowpan.=20 >=20 > OK, but there are many different link types other than > just IEEE 802.15.4 that don't support 1280 natively. > They can either use a link-specific adaptation (many > do), or they can use something that is ubiquitously > available and link-agnostic. >=20 > Thanks - Fred > fred.l.templin@boeing.com From Fred.L.Templin@boeing.com Fri Feb 11 13:45:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41483A69DA for ; Fri, 11 Feb 2011 13:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n56z7z9O7E7Z for ; Fri, 11 Feb 2011 13:45:30 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id DB09E3A699F for ; Fri, 11 Feb 2011 13:45:30 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1BLiwaB026574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Feb 2011 13:44:58 -0800 (PST) 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 p1BLivnU019041; Fri, 11 Feb 2011 13:44:57 -0800 (PST) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1BLifBc018685 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 11 Feb 2011 13:44:57 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Fri, 11 Feb 2011 13:44:56 -0800 From: "Templin, Fred L" To: Fred Baker Date: Fri, 11 Feb 2011 13:44:56 -0800 Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvKMf+dNUjaZfpTTxCMnDx3adzYRwAApfwA Message-ID: References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichli d .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><20 1 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> <5D7635B4-E2E0-4828-AF4E-EDE521EF7FCB@cisco.com> <4B737278-9754-4583-A639-BC8022205582@cisco.com> <2C989009-9999-4170-B368-678F04CFCB29@cisco.com> <614D672D-1013-4B72-9413-86C61B5B816D@cisco.com> In-Reply-To: <614D672D-1013-4B72-9413-86C61B5B816D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 21:45:31 -0000 =20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Friday, February 11, 2011 1:03 PM > To: Templin, Fred L > Cc: Matt Crawford; v6ops@ietf.org > Subject: Re: [v6ops] RFC 2464 - MTU >1500 >=20 > I frankly think it would be more sensible to accept that the=20 > MTU might sometimes be less than 1280. So...change the specs to allow IPv6 to operate over links that support less than 1280 natively? What would you like to name as the new IPv6 MinMTU - 576? 68? Something else? Fred fred.l.templin@boeing.com > On Feb 11, 2011, at 12:57 PM, Templin, Fred L wrote: >=20 > > Hi Fred,=20 > >=20 > >> -----Original Message----- > >> From: Fred Baker [mailto:fred@cisco.com]=20 > >> Sent: Friday, February 11, 2011 11:54 AM > >> To: Templin, Fred L > >> Cc: Matt Crawford; v6ops@ietf.org > >> Subject: Re: [v6ops] RFC 2464 - MTU >1500 > >>=20 > >>=20 > >> On Feb 11, 2011, at 11:42 AM, Templin, Fred L wrote: > >>=20 > >>> So, we need to find some way to convey 1280 IPv6 packets > >>> over those sorts of links since IPv6 does not permit > >>> in-the-network fragmentation. So, there needs to be some > >>> segmentation/reassembly at a layer below IPv6.=20 > >>=20 > >> I think you would generally be told that's 6lowpan.=20 > >=20 > > OK, but there are many different link types other than > > just IEEE 802.15.4 that don't support 1280 natively. > > They can either use a link-specific adaptation (many > > do), or they can use something that is ubiquitously > > available and link-agnostic. > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com >=20 > = From fred@cisco.com Fri Feb 11 14:03:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983F63A68C0 for ; Fri, 11 Feb 2011 14:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.438 X-Spam-Level: X-Spam-Status: No, score=-110.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axejhzourLKP for ; Fri, 11 Feb 2011 14:03:37 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8B5FA3A680E for ; Fri, 11 Feb 2011 14:03:37 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEBAKFBVU2rR7Ht/2dsb2JhbACXGo5dc59QmzaFXQSFAYZ7gzI X-IronPort-AV: E=Sophos;i="4.60,458,1291593600"; d="scan'208";a="258873713" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 11 Feb 2011 22:03:33 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1BM3Ssi013466; Fri, 11 Feb 2011 22:03:33 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Fri, 11 Feb 2011 23:03:33 +0100 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Fri, 11 Feb 2011 23:03:33 +0100 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Fri, 11 Feb 2011 14:03:18 -0800 Message-Id: <94840F7A-6350-443B-94F4-30299806172C@cisco.com> References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichli d .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><20 1 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> <5D7635B4-E2E0-4828-AF4E-EDE521EF7FCB@cisco.com> <4B737278-9754-4583-A639-BC8022205582@cisco.com> <2C989009-9999-4170-B368-678F04CFCB29@cisco.com> <614D672D-1013-4B72-9413-86C61B5B816D@cisco.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 22:03:38 -0000 My suggestion: an IPv6 MTU should be at least the size of an IPv6 = header. Not that I would recommend anyone set their MTU to that, but my = observation of pompous statements about what else it should be are = rooted in fantasy. Pick any number larger than that size and give me a = technical argument for it - I think you'll find it difficult without = making assumptions about the network. The reason for the magic size 576, = for example, had something to do with the size of disk blocks on common = media, and as a result with the size of a buffer on equipment of the = day. Having been a builder of "routers of the day", I'd note that the = router I worked on put 90 data bytes in a buffer (but they were designed = to chain). On Feb 11, 2011, at 1:44 PM, Templin, Fred L wrote: >=20 >=20 >> -----Original Message----- >> From: Fred Baker [mailto:fred@cisco.com]=20 >> Sent: Friday, February 11, 2011 1:03 PM >> To: Templin, Fred L >> Cc: Matt Crawford; v6ops@ietf.org >> Subject: Re: [v6ops] RFC 2464 - MTU >1500 >>=20 >> I frankly think it would be more sensible to accept that the=20 >> MTU might sometimes be less than 1280. >=20 > So...change the specs to allow IPv6 to operate over > links that support less than 1280 natively? >=20 > What would you like to name as the new IPv6 > MinMTU - 576? 68? Something else? >=20 > Fred > fred.l.templin@boeing.com >=20 >> On Feb 11, 2011, at 12:57 PM, Templin, Fred L wrote: >>=20 >>> Hi Fred,=20 >>>=20 >>>> -----Original Message----- >>>> From: Fred Baker [mailto:fred@cisco.com]=20 >>>> Sent: Friday, February 11, 2011 11:54 AM >>>> To: Templin, Fred L >>>> Cc: Matt Crawford; v6ops@ietf.org >>>> Subject: Re: [v6ops] RFC 2464 - MTU >1500 >>>>=20 >>>>=20 >>>> On Feb 11, 2011, at 11:42 AM, Templin, Fred L wrote: >>>>=20 >>>>> So, we need to find some way to convey 1280 IPv6 packets >>>>> over those sorts of links since IPv6 does not permit >>>>> in-the-network fragmentation. So, there needs to be some >>>>> segmentation/reassembly at a layer below IPv6.=20 >>>>=20 >>>> I think you would generally be told that's 6lowpan.=20 >>>=20 >>> OK, but there are many different link types other than >>> just IEEE 802.15.4 that don't support 1280 natively. >>> They can either use a link-specific adaptation (many >>> do), or they can use something that is ubiquitously >>> available and link-agnostic. >>>=20 >>> Thanks - Fred >>> fred.l.templin@boeing.com >>=20 >>=20 From rja.lists@gmail.com Fri Feb 11 14:04:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6819B3A699F for ; Fri, 11 Feb 2011 14:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFm1+QPUlHb4 for ; Fri, 11 Feb 2011 14:04:35 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 7B1113A680E for ; Fri, 11 Feb 2011 14:04:34 -0800 (PST) Received: by qyk34 with SMTP id 34so13761qyk.10 for ; Fri, 11 Feb 2011 14:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=10FrWBSyZuaKSrxq0FDWD1fbzNQB910iKn9oYjirqwI=; b=GnTe3xi8boUSLTVtBMqZkXSYSFvs8FcFwqq81vD/HIzy8yvcq9oE4l/wmjmXOkpXHI LbZQfEKIuiJILVGvUrAlcBce6807jte1rv6TSJGr6K5NZ8g2nCjlfVTYioKqxUbGSeKg efx230oVn69cA9rpWRJRJhBSPADWh23/GmQLk= 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=DU1vMG3oqKEfHFaxNaCoEb70lmLa+Gs4xvQ9qnM9y0SIl/OzSmm/n7zA8NHnzQA3XY puy8NxAUfVMGQjMpc4LrqyjxSuq8wE7MVCILj6yD/bcbP+NY0+E/0fy1BHURlQxUVblw Qz8+I54kJAGinBMpwUfDi1SVid32AKmjvgdIU= Received: by 10.224.176.77 with SMTP id bd13mr1144761qab.156.1297461889855; Fri, 11 Feb 2011 14:04:49 -0800 (PST) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id y17sm887732qci.9.2011.02.11.14.04.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Feb 2011 14:04:49 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Feb 2011 17:04:47 -0500 Message-Id: To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 22:04:36 -0000 Because of issues with file transfer throughput, originally=20 arising in the high-performance computing world which was=20 moving from ATM to GigE in the late 1990s, nearly all=20 1 Gig Ethernet products have supported an IP MTU of 9180 bytes=20 for at least a decade now. =20 The computing issues addressed by GigE jumbograms and the=20 reason for the 9180 byte IP MTU size are amply documented=20 in an old ATM-related document, RFC-1626. For migration reasons and to avoid fragmentation, Ethernet jumbograms=20 needed to be at least as big as the ATM jumbogram size. The combination of CSMA/CD at the link-layer (e.g. big yellow Ethernet cables) and jumbograms can create real=20 technical issues. This reportedly has caused IEEE to decline=20 to formally standardise jumbograms for Ethernet. Despite that, support for Ethernet jumbograms is a marketplace requirement and is (AFAICT) universally available in deployed 1/10 GigE products today. Earlier, Fred Baker wrote: > >=20 > I think the right thing to do is (C), an update to 2464 and the = various RFCs > that refer to a magic numbers 1500 or 1280, indicating that IPv6 MTU > *in*all*cases* follows the same rules as IPv4, which is to say that it = uses > defaults appropriate to the characteristics of the link layer and > is subject to local configuration, DHCP configuration, TCP MSS = negotiation, > and Path MTU. >=20 > The number "1280" is important in a world where IPv6 is primarily = carried > in tunnels, and 1500 is important to Ethernets below 1 Gig. But we = are > in the process of making IPv6 native, and have link layer MTUs as = small > as 128 without a means to link fragments of higher layer protocols = together > (so the rule trying to impose that on link layer protocols is broken) > and as high as 18,000 (Token thing). I agree with Fred on the above. =20 I objected to setting the magic 1280 byte number low back ~15 years=20 ago (IETF IPng WG minutes, December 1994). At the time, I was=20 thinking about certain SATCOM link layers (some of that link technology=20= is still deployed, btw). Since then, I know of other link layers=20 that have this issue. At the same IETF IPng WG meeting, an equivalent=20= issue was identified with AppleTalk. Fred has now pointed out that=20 802.15.4 and other link layers have this issue. =20 Tunneling isn't the answer here. It consumes precious bandwidth, requires more CPU, and requires more memory. All of these are scarce. For example, the SATCOM definition of "high bandwidth" is=20 several orders of magnitude smaller than the 10 Gbps links that ISPs would call "high bandwidth". If IPv6 is going to really replace IPv4, then Fred's suggestions above really ought to be made to the standards. My guess is that if IPv6 does not make those changes, then folks will only run IPv4 over those constrained link types (which is what seems=20 to have happened in the past ~15 years, AFAICT). That is not an outcome that helps IPv6 be widely deployed natively. Yours, Ran Atkinson From Fred.L.Templin@boeing.com Fri Feb 11 14:13:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD403A6853 for ; Fri, 11 Feb 2011 14:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.418 X-Spam-Level: X-Spam-Status: No, score=-6.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1p7uJ3-xpZa for ; Fri, 11 Feb 2011 14:13:01 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id BB1FE3A680E for ; Fri, 11 Feb 2011 14:13:01 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1BMDG3B009711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Feb 2011 14:13:16 -0800 (PST) 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 p1BMDGi1005070; Fri, 11 Feb 2011 14:13:16 -0800 (PST) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1BMDFKS005058 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 11 Feb 2011 14:13:16 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Fri, 11 Feb 2011 14:13:15 -0800 From: "Templin, Fred L" To: Fred Baker Date: Fri, 11 Feb 2011 14:13:15 -0800 Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvKN/WDHqQnjSQnTEC+5z5y8GXzeQAAIUVQ Message-ID: References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichli d .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><20 1 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> <5D7635B4-E2E0-4828-AF4E-EDE521EF7FCB@cisco.com> <4B737278-9754-4583-A639-BC8022205582@cisco.com> <2C989009-9999-4170-B368-678F04CFCB29@cisco.com> <614D672D-1013-4B72-9413-86C61B5B816D@cisco.com> <94840F7A-6350-443B-94F4-30299806172C@cisco.com> In-Reply-To: <94840F7A-6350-443B-94F4-30299806172C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 22:13:03 -0000 Hi Fred,=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Friday, February 11, 2011 2:03 PM > To: Templin, Fred L > Cc: Matt Crawford; v6ops@ietf.org > Subject: Re: [v6ops] RFC 2464 - MTU >1500 >=20 > My suggestion: an IPv6 MTU should be at least the size of an=20 > IPv6 header. Not that I would recommend anyone set their MTU=20 > to that, but my observation of pompous statements about what=20 > else it should be are rooted in fantasy. Pick any number=20 > larger than that size and give me a technical argument for it=20 > - I think you'll find it difficult without making assumptions=20 > about the network. The reason for the magic size 576, for=20 > example, had something to do with the size of disk blocks on=20 > common media, and as a result with the size of a buffer on=20 > equipment of the day. Having been a builder of "routers of=20 > the day", I'd note that the router I worked on put 90 data=20 > bytes in a buffer (but they were designed to chain). I'm not sure I quite get from this whether you are advocating a reduction in the IPv6 MinMTU to allow MTUs smaller than 1280. Are you? Is it possible we could actually find some common ground to agree on? BTW, this has nothing whatsoever to do with advocating for tunnels, which I am specifically not doing. Thanks - Fred fred.l.templin@boeing.com =20 > On Feb 11, 2011, at 1:44 PM, Templin, Fred L wrote: >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Fred Baker [mailto:fred@cisco.com]=20 > >> Sent: Friday, February 11, 2011 1:03 PM > >> To: Templin, Fred L > >> Cc: Matt Crawford; v6ops@ietf.org > >> Subject: Re: [v6ops] RFC 2464 - MTU >1500 > >>=20 > >> I frankly think it would be more sensible to accept that the=20 > >> MTU might sometimes be less than 1280. > >=20 > > So...change the specs to allow IPv6 to operate over > > links that support less than 1280 natively? > >=20 > > What would you like to name as the new IPv6 > > MinMTU - 576? 68? Something else? > >=20 > > Fred > > fred.l.templin@boeing.com > >=20 > >> On Feb 11, 2011, at 12:57 PM, Templin, Fred L wrote: > >>=20 > >>> Hi Fred,=20 > >>>=20 > >>>> -----Original Message----- > >>>> From: Fred Baker [mailto:fred@cisco.com]=20 > >>>> Sent: Friday, February 11, 2011 11:54 AM > >>>> To: Templin, Fred L > >>>> Cc: Matt Crawford; v6ops@ietf.org > >>>> Subject: Re: [v6ops] RFC 2464 - MTU >1500 > >>>>=20 > >>>>=20 > >>>> On Feb 11, 2011, at 11:42 AM, Templin, Fred L wrote: > >>>>=20 > >>>>> So, we need to find some way to convey 1280 IPv6 packets > >>>>> over those sorts of links since IPv6 does not permit > >>>>> in-the-network fragmentation. So, there needs to be some > >>>>> segmentation/reassembly at a layer below IPv6.=20 > >>>>=20 > >>>> I think you would generally be told that's 6lowpan.=20 > >>>=20 > >>> OK, but there are many different link types other than > >>> just IEEE 802.15.4 that don't support 1280 natively. > >>> They can either use a link-specific adaptation (many > >>> do), or they can use something that is ubiquitously > >>> available and link-agnostic. > >>>=20 > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>=20 > >>=20 >=20 > = From moore@network-heretics.com Fri Feb 11 14:53:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ADFA3A6853 for ; Fri, 11 Feb 2011 14:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id he0RZhidFXMq for ; Fri, 11 Feb 2011 14:53:52 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id 13B3B3A680E for ; Fri, 11 Feb 2011 14:53:52 -0800 (PST) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 8AC9F20DDB; Fri, 11 Feb 2011 17:54:07 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 11 Feb 2011 17:54:07 -0500 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=wk6OHMnCQBtktQJX9tAtAgT52ZE=; b=VPHzTv1J5CVFphaVsgYSYievsWdwySENkI/Lij5EVvHgHSKTKOzs+y+AFLx409bQhTRMuqqlMe49YHEKpqWOSQd8QKFW1RJpXMLC66wHbElBv6ciFD6yHIcoo/CSO0mQ9Z7uQ97F+TMIqRgZO+JxB+ogRQ+wJ0+Qf5VkCokUPwM= X-Sasl-enc: J7GOteleuIIXDWq4NcXNM5r4A5EexurIRrtGmwj1xfMV 1297464845 Received: from 173-6-180-61.pools.spcsdns.net (unknown [173.6.180.61]) by mail.messagingengine.com (Postfix) with ESMTPA id 3141B441FBB; Fri, 11 Feb 2011 17:54:00 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <614D672D-1013-4B72-9413-86C61B5B816D@cisco.com> Date: Fri, 11 Feb 2011 17:53:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <657FD122-63D2-49D7-9955-A24B73A57D6D@network-heretics.com> References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichli d .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><20 1 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> <5D7635B4-E2E0-4828-AF4E-EDE521EF7FCB@cisco.com> <4B737278-9754-4583-A639-BC8022205582@cisco.com> <2C989009-9999-4170-B368-678F04CFCB29@cisco.com> <614D672D-1013-4B72-9413-86C61B5B816D@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1082) Cc: Matt Crawford , "v6ops@ietf.org" Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 22:53:53 -0000 In general, I think it's extremely late to talk about changing the IPv6 = minimum MTU. =20 Even if you were going to relax that restriction and found a way to do = it without breaking compatibility with widely deployed code, the IPv6 = header is just too big to be used with very small packets. For those, = it makes sense to have an adaptation layer with a small header, and = maybe FEC to deal with dropped fragments. Keith On Feb 11, 2011, at 4:02 PM, Fred Baker wrote: > I frankly think it would be more sensible to accept that the MTU might = sometimes be less than 1280. >=20 > On Feb 11, 2011, at 12:57 PM, Templin, Fred L wrote: >=20 >> Hi Fred,=20 >>=20 >>> -----Original Message----- >>> From: Fred Baker [mailto:fred@cisco.com]=20 >>> Sent: Friday, February 11, 2011 11:54 AM >>> To: Templin, Fred L >>> Cc: Matt Crawford; v6ops@ietf.org >>> Subject: Re: [v6ops] RFC 2464 - MTU >1500 >>>=20 >>>=20 >>> On Feb 11, 2011, at 11:42 AM, Templin, Fred L wrote: >>>=20 >>>> So, we need to find some way to convey 1280 IPv6 packets >>>> over those sorts of links since IPv6 does not permit >>>> in-the-network fragmentation. So, there needs to be some >>>> segmentation/reassembly at a layer below IPv6.=20 >>>=20 >>> I think you would generally be told that's 6lowpan.=20 >>=20 >> OK, but there are many different link types other than >> just IEEE 802.15.4 that don't support 1280 natively. >> They can either use a link-specific adaptation (many >> do), or they can use something that is ubiquitously >> available and link-agnostic. >>=20 >> Thanks - Fred >> fred.l.templin@boeing.com >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Fri Feb 11 15:03:32 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FD903A680E for ; Fri, 11 Feb 2011 15:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9khia1zqSu3 for ; Fri, 11 Feb 2011 15:03:30 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 5035C3A6834 for ; Fri, 11 Feb 2011 15:03:30 -0800 (PST) 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 p1BN3gtY017774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Feb 2011 17:03:42 -0600 (CST) 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 p1BN3g1W010421; Fri, 11 Feb 2011 17:03:42 -0600 (CST) 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 p1BN3fEV010395 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 11 Feb 2011 17:03:42 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Fri, 11 Feb 2011 15:03:41 -0800 From: "Templin, Fred L" To: Keith Moore , Fred Baker Date: Fri, 11 Feb 2011 15:03:40 -0800 Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvKPqwVfnpGE0GjR3yw6CgZRg/ynAAAHmCQ Message-ID: References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichli d .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><20 1 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><8AFE5D7F-5F9A-4526-BED1-8A8766A25E44@fnal.gov> <5D7635B4-E2E0-4828-AF4E-EDE521EF7FCB@cisco.com> <4B737278-9754-4583-A639-BC8022205582@cisco.com> <2C989009-9999-4170-B368-678F04CFCB29@cisco.com> <614D672D-1013-4B72-9413-86C61B5B816D@cisco.com> <657FD122-63D2-49D7-9955-A24B73A57D6D@network-heretics.com> In-Reply-To: <657FD122-63D2-49D7-9955-A24B73A57D6D@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 Cc: "v6ops@ietf.org" , Matt Crawford Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 23:03:32 -0000 =20 > -----Original Message----- > From: Keith Moore [mailto:moore@network-heretics.com]=20 > Sent: Friday, February 11, 2011 2:54 PM > To: Fred Baker > Cc: Templin, Fred L; v6ops@ietf.org; Matt Crawford > Subject: Re: [v6ops] RFC 2464 - MTU >1500 >=20 > In general, I think it's extremely late to talk about=20 > changing the IPv6 minimum MTU. Too late? Maybe. Worth discussing? Hmm... =20 > Even if you were going to relax that restriction and found a=20 > way to do it without breaking compatibility with widely=20 > deployed code, the IPv6 header is just too big to be used=20 > with very small packets. Well, the 68 in IPv4 came from a maximally-large IPv4 header (60 bytes) plus 8 bytes for the minimum-sized fragment. > For those, it makes sense to have=20 > an adaptation layer with a small header, and maybe FEC to=20 > deal with dropped fragments. FEC and/or ARQ - which is what many of the wireless links I deal with do. Still - how long are the end systems willing to wait for a 1280 IPv6 packet to finally make it through a constrained link? Fred fred.l.templin@boeing.com > Keith >=20 > On Feb 11, 2011, at 4:02 PM, Fred Baker wrote: >=20 > > I frankly think it would be more sensible to accept that=20 > the MTU might sometimes be less than 1280. > >=20 > > On Feb 11, 2011, at 12:57 PM, Templin, Fred L wrote: > >=20 > >> Hi Fred,=20 > >>=20 > >>> -----Original Message----- > >>> From: Fred Baker [mailto:fred@cisco.com]=20 > >>> Sent: Friday, February 11, 2011 11:54 AM > >>> To: Templin, Fred L > >>> Cc: Matt Crawford; v6ops@ietf.org > >>> Subject: Re: [v6ops] RFC 2464 - MTU >1500 > >>>=20 > >>>=20 > >>> On Feb 11, 2011, at 11:42 AM, Templin, Fred L wrote: > >>>=20 > >>>> So, we need to find some way to convey 1280 IPv6 packets > >>>> over those sorts of links since IPv6 does not permit > >>>> in-the-network fragmentation. So, there needs to be some > >>>> segmentation/reassembly at a layer below IPv6.=20 > >>>=20 > >>> I think you would generally be told that's 6lowpan.=20 > >>=20 > >> OK, but there are many different link types other than > >> just IEEE 802.15.4 that don't support 1280 natively. > >> They can either use a link-specific adaptation (many > >> do), or they can use something that is ubiquitously > >> available and link-agnostic. > >>=20 > >> Thanks - Fred > >> fred.l.templin@boeing.com > >=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > = From swmike@swm.pp.se Fri Feb 11 16:54:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E1B13A6A57 for ; Fri, 11 Feb 2011 16:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OkrF++yOoyl for ; Fri, 11 Feb 2011 16:54:33 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id F35463A6A21 for ; Fri, 11 Feb 2011 16:54:32 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 189EF9C; Sat, 12 Feb 2011 01:54:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 181FB9A for ; Sat, 12 Feb 2011 01:54:46 +0100 (CET) Date: Sat, 12 Feb 2011 01:54:46 +0100 (CET) From: Mikael Abrahamsson To: v6ops@ietf.org In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13A23@RWC-EX1.corp.seven.com> Message-ID: References: <20110203224351.GA27225@srv03.cluenet.de> <201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com> <20110207211826.GB13323@srv03.cluenet.de> <4ABF4068-018A-4D24-93A7-B1069AC99333@fnal.gov> <20110208074710.GB18776@srv03.cluenet.de><201102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com> <4D54A15D.4050700@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC13A23@RWC-EX1.corp.seven.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 00:54:34 -0000 On Thu, 10 Feb 2011, George Bonser wrote: > doesn't break anything out on the internet, we send a SYN and when the > other end replies, they have their MSS which is the maximum segment size > so we won't try to send a packet larger than that no matter what the MTU > is set to. For TCP yes, for all the other protos, not so much. There you need PMTUD working properly. -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Fri Feb 11 17:21:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF87E3A6A62 for ; Fri, 11 Feb 2011 17:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.448 X-Spam-Level: X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82FV5zIVvfKA for ; Fri, 11 Feb 2011 17:21:08 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id C0ECE3A6A21 for ; Fri, 11 Feb 2011 17:21:04 -0800 (PST) Received: by qyj19 with SMTP id 19so2375090qyj.10 for ; Fri, 11 Feb 2011 17:21:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bI/1OIPvkLw4YC63PGSbERppoA1G3wA93cyHTPCadEY=; b=OdCD4mLPUHpsFq//Hl9ND7tGCLvsLsC7yBytoWwitJ5YrCd8iRRsPMIjldnSHqkGDW dz4/X7URf70VU1fQs7Ihqqes8GSjA97niQuBw00oC4VW9t/fml5yBzedCnkzgvuWBmnT iwAu4rYS/8Q6Rl0rCNAGq0ln7ZKJp/HUbTmbI= 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=Q7pL3JYZDuiWDXmcmShYfoJwoPJ9E0OhM/7Uzj1PvsrxIEpEyyhlhoNLsM0ajzLY66 W3xNdRTTrbosTflSmKud+JdfC+mr7Y9xOaYsgORAC/Ldc/yRXJB//0xaFIkhU3kZ1eC7 HASaQuKZmYAbNAWkNb/Y6QwTzLfGRWG3NWk4M= Received: by 10.224.214.71 with SMTP id gz7mr1211874qab.349.1297473680632; Fri, 11 Feb 2011 17:21:20 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id nb15sm1018147qcb.2.2011.02.11.17.21.18 (version=SSLv3 cipher=OTHER); Fri, 11 Feb 2011 17:21:20 -0800 (PST) Message-ID: <4D55E087.9090106@gmail.com> Date: Sat, 12 Feb 2011 14:21:11 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson References: <20110203224351.GA27225@srv03.cluenet.de> <201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com> <20110207211826.GB13323@srv03.cluenet.de> <4ABF4068-018A-4D24-93A7-B1069AC99333@fnal.gov> <20110208074710.GB18776@srv03.cluenet.de><201102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com> <4D54A15D.4050700@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC13A23@RWC-EX1.corp.seven.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 01:21:08 -0000 On 2011-02-12 13:54, Mikael Abrahamsson wrote: > On Thu, 10 Feb 2011, George Bonser wrote: > >> doesn't break anything out on the internet, we send a SYN and when the >> other end replies, they have their MSS which is the maximum segment size >> so we won't try to send a packet larger than that no matter what the MTU >> is set to. > > For TCP yes, for all the other protos, not so much. There you need PMTUD > working properly. > For TCP, no. This is exactly the failure mode that I (oh, the irony, says the co-author of RFC 3056) experienced when running 6to4 a couple of years ago. It's entirely possible to conduct a successful SYN-SYN/ACK exchange and end up with the MSS being greater than the path MTU, even if the client's link MTU is set to 1280 while the server's is set to 1500. Brian From gbonser@seven.com Fri Feb 11 18:07:32 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F8D3A6849 for ; Fri, 11 Feb 2011 18:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E4+pwkqeh86 for ; Fri, 11 Feb 2011 18:07:31 -0800 (PST) Received: from wex.seven.com (wex.seven.com [208.87.204.25]) by core3.amsl.com (Postfix) with ESMTP id 62C8B3A6827 for ; Fri, 11 Feb 2011 18:07:30 -0800 (PST) Received: from wex.seven.com ([10.1.16.28]) by wex.seven.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Feb 2011 18:07:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Feb 2011 18:07:45 -0800 Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13A6A@RWC-EX1.corp.seven.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvKT3sLon3PIgjCS9Ob4C2WC9xeBQACgonQ References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><201102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok.net><5A6D953473350C4B9995546AFE9939EE0BC13A23@RWC-EX1.corp.seven.com> From: "George Bonser" To: "Mikael Abrahamsson" , X-OriginalArrivalTime: 12 Feb 2011 02:07:47.0197 (UTC) FILETIME=[A48FAAD0:01CBCA59] Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 02:07:32 -0000 >=20 > For TCP yes, for all the other protos, not so much. There you need > PMTUD > working properly. >=20 Yes, and as modern PMTUD doesn't require ICMP, it works much better than the old way. From swmike@swm.pp.se Fri Feb 11 18:35:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60CC63A6A88 for ; Fri, 11 Feb 2011 18:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MjPapvh70tf for ; Fri, 11 Feb 2011 18:35:27 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 4EB253A6A82 for ; Fri, 11 Feb 2011 18:35:27 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9F7D99C; Sat, 12 Feb 2011 03:35:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9C5CC9A; Sat, 12 Feb 2011 03:35:40 +0100 (CET) Date: Sat, 12 Feb 2011 03:35:40 +0100 (CET) From: Mikael Abrahamsson To: George Bonser In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13A6A@RWC-EX1.corp.seven.com> Message-ID: References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><201102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok.net><5A6D953473350C4B9995546AFE9939EE0BC13A23@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13A6A@RWC-EX1.corp.seven.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 02:35:28 -0000 On Fri, 11 Feb 2011, George Bonser wrote: > Yes, and as modern PMTUD doesn't require ICMP, it works much better than > the old way. Care to elaborate on that? What "modern PMTUD" are you referring to that doesn't require any ICMP involvement? -- Mikael Abrahamsson email: swmike@swm.pp.se From gbonser@seven.com Fri Feb 11 21:46:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A1A3A6A87 for ; Fri, 11 Feb 2011 21:46:05 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edRbu39AOrDO for ; Fri, 11 Feb 2011 21:46:04 -0800 (PST) Received: from wex.seven.com (wex.seven.com [208.87.204.25]) by core3.amsl.com (Postfix) with ESMTP id 4776E3A6897 for ; Fri, 11 Feb 2011 21:46:03 -0800 (PST) Received: from wex.seven.com ([10.1.16.28]) by wex.seven.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Feb 2011 21:46:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Feb 2011 21:46:19 -0800 Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13A72@RWC-EX1.corp.seven.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvKXYxSa16EQfDYStWlBdLFHzFwQgAGYvCQ References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><201102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok.net><5A6D953473350C4B9995546AFE9939EE0BC13A23@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13A6A@RWC-EX1.corp.seven.com> From: "George Bonser" To: "Mikael Abrahamsson" X-OriginalArrivalTime: 12 Feb 2011 05:46:20.0178 (UTC) FILETIME=[2C81C720:01CBCA78] Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 05:46:05 -0000 http://www.ietf.org/rfc/rfc4821.txt On by default with Windows and Solaris. Need to set net.ipv4.tcp_mtu_probing=3D1 or 2 for linux depending on the behavior = you want. > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Friday, February 11, 2011 6:36 PM > To: George Bonser > Cc: v6ops@ietf.org > Subject: RE: [v6ops] RFC 2464 - MTU >1500 >=20 > On Fri, 11 Feb 2011, George Bonser wrote: >=20 > > Yes, and as modern PMTUD doesn't require ICMP, it works much better > than > > the old way. >=20 > Care to elaborate on that? What "modern PMTUD" are you referring to > that > doesn't require any ICMP involvement? >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se From gbonser@seven.com Fri Feb 11 21:57:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 403F73A6897 for ; Fri, 11 Feb 2011 21:57:10 -0800 (PST) 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_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puhWtLNuyti8 for ; Fri, 11 Feb 2011 21:57:09 -0800 (PST) Received: from wex.seven.com (wex.seven.com [208.87.204.25]) by core3.amsl.com (Postfix) with ESMTP id 94B523A6850 for ; Fri, 11 Feb 2011 21:57:09 -0800 (PST) Received: from wex.seven.com ([10.1.16.28]) by wex.seven.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Feb 2011 21:57:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Feb 2011 21:57:24 -0800 Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13A73@RWC-EX1.corp.seven.com> In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13A72@RWC-EX1.corp.seven.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvKXYxSa16EQfDYStWlBdLFHzFwQgAGYvCQAACgM5A= References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichlid.raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><201102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok.net><5A6D953473350C4B9995546AFE9939EE0BC13A23@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0BC13A6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13A72@RWC-EX1.corp.seven.com> From: "George Bonser" To: "Mikael Abrahamsson" X-OriginalArrivalTime: 12 Feb 2011 05:57:26.0053 (UTC) FILETIME=[B9663D50:01CBCA79] Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 05:57:10 -0000 Note: while that sysctl is in the ipv4 path, it is effective for both v4 and v6, it is for general TCP of both protocols. > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of George Bonser > Sent: Friday, February 11, 2011 9:46 PM > To: Mikael Abrahamsson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] RFC 2464 - MTU >1500 >=20 > http://www.ietf.org/rfc/rfc4821.txt >=20 > On by default with Windows and Solaris. Need to set > net.ipv4.tcp_mtu_probing=3D1 or 2 for linux depending on the behavior you > want. >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > > Sent: Friday, February 11, 2011 6:36 PM > > To: George Bonser > > Cc: v6ops@ietf.org > > Subject: RE: [v6ops] RFC 2464 - MTU >1500 > > > > On Fri, 11 Feb 2011, George Bonser wrote: > > > > > Yes, and as modern PMTUD doesn't require ICMP, it works much better > > than > > > the old way. > > > > Care to elaborate on that? What "modern PMTUD" are you referring to > > that > > doesn't require any ICMP involvement? > > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From frnkblk@iname.com Fri Feb 11 23:09:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5401A3A6894 for ; Fri, 11 Feb 2011 23:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1U-lZqAitk4 for ; Fri, 11 Feb 2011 23:09:20 -0800 (PST) Received: from premieronline.net (smtp2-3.premieronline.net [96.31.0.28]) by core3.amsl.com (Postfix) with ESMTP id CD3413A6850 for ; Fri, 11 Feb 2011 23:09:19 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.27; Received: from BULKFAMLAPTOP (unverified [199.120.69.27]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 22252651-1729245 for multiple; Sat, 12 Feb 2011 01:09:33 -0600 From: "Frank Bulk" To: "'Pekka Savola'" , "Brian E Carpenter" References: <4D5336F8.9080506@gmail.com> <61F0E9D3-19D1-4F26-A167-022FBB618834@apple.com> <20110210072104.GA5220@srv03.cluenet.de> <09746C7E-1BB8-4DAD-9FE6-9FC05FE9AE87@apple.com> <4D543F94.8090505@gmail.com> In-Reply-To: Date: Sat, 12 Feb 2011 01:09:32 -0600 Message-ID: <019a01cbca83$cc7f9170$657eb450$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcvJtvp/oI5Ex71gTBqSPrF2L/+UPAAzMr5g Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (useraccess) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=0 Friend=4 Surbl=0 Catch=0 r=0 ip=199.120.69.27 X-IP-stats: Incoming Outgoing Last 0, First 706, in=9512564, out=36793, spam=0 Known=true ip=199.120.69.27 Cc: IPv6 Operations Subject: Re: [v6ops] 6to4 reliability check X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 07:09:21 -0000 Someone willing to write a NAGIOS plugin? Frank -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Pekka Savola Sent: Friday, February 11, 2011 12:42 AM To: Brian E Carpenter Cc: IPv6 Operations Subject: Re: [v6ops] 6to4 reliability check On Fri, 11 Feb 2011, Brian E Carpenter wrote: > " Unless the answer to all these questions is 'yes', subscribers will > be no worse off, and possibly better off, if the route to 192.88.99.1 > is blocked and generates 'destination unreachable'. At least one > host implementation (Windows XP) starts with a 'ping' to the anycast > address, so will quickly learn that 6to4 is not available [Savola]." I do not know if an (IPv4) destination unreachable will propagate to the application (or the stack). Windows uses the method as a qualification procedure (if it doesn't work, the 6to4 relay is not used) and as such it won't get reported to the applications in such a manner that e.g. ICMPv6 error would be or how you probably hope that ICMPv4 would be. So, I would suggest the following caveat to the former (unless we get info on how implementations react -- preferable), and more precise on the methodology: Unless the answer to all these questions is 'yes', subscribers will be no worse off, and possibly better off, if the route to 192.88.99.1 is blocked and generates an IPv4 'destination unreachable'. There is little operational experience with this, however. Some implementations also perform some form of 6to4 relay qualification. For example, a host implementation (Windows) tests the protocol-41 reachability by sending an ICMPv6 echo request with Hop Limit=1 to the relay, expecting a response or Hop Limit exceeded error back. Lack of any response indicates that the 6to4 relay does not work and it is turned off [Savola]. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From gert@space.net Sat Feb 12 05:09:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 409BB3A6A7C for ; Sat, 12 Feb 2011 05:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEVSTwwbsCQo for ; Sat, 12 Feb 2011 05:09:01 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by core3.amsl.com (Postfix) with ESMTP id D033C3A6A71 for ; Sat, 12 Feb 2011 05:08:59 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id AE102F80FE for ; Sat, 12 Feb 2011 14:09:14 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8E971F8111 for ; Sat, 12 Feb 2011 14:09:14 +0100 (CET) Received: (qmail 75157 invoked by uid 1007); 12 Feb 2011 14:09:14 +0100 Date: Sat, 12 Feb 2011 14:09:14 +0100 From: Gert Doering To: Keith Moore Message-ID: <20110212130914.GZ44800@Space.Net> References: <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Daniel Roesen , "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 13:09:02 -0000 Hi, On Tue, Feb 08, 2011 at 06:34:11PM -0500, Keith Moore wrote: > I certainly get that impression from many of the participants > here. There's definitely an ideology that use of 6to4 is somehow > not legitimate and that it's therefore acceptable to sabotage it > rather than to try to fix it. This is completely missing the point. 6to4 is already today frequently not working in a way that's not possible to fix, because there's no way to figure out for a user who's 6to4 relay is breaking his *return* packets. If there were a central Internet authority that could order ISPs to properly run their 6to4 relays, this might change, but there isn't. Furthermore, 6to4 brokenness will go up due to the inevitable addition of CGN/LSNs due to IPv4 run-out. The point therefore is: if we cannot *fix* 6to4, due to the way the reality is, can we remove it from the list of things that will cause breakage in the transition to native IPv6, for example by having it "disabled-by-default" in client OSes and CPE OSes? Nobody is advocating to go out and "filter proto 41, just for the sake of it" or "mandate that Microsoft will remove 6to4 support from their stacks" ("default-off" and "remove completely" are very much different things for those that know what they want). [..] > The idea that the internet's only purpose is for users to get "content" has always struck me as bizarre. It wasn't built that way, but that's what it is today. Not its only purpose, but that's where most of the money required to make it work is coming from. [..] > CGN is also going to make existing services break, likely causing users to switch ISPs. If "lots of users" are going to switch ISP to a new ISP without CGN - what's that ISP going to do, if all these new customers burn up his IPv4 space? Cough up new IPv4 /8s, to keep "offering IPv4 Internet without CGN"? [..] > But when operators start blaming 6to4 on problems that were actually caused by operators, it's hard to see how they can find suitable solutions. Maybe you should remember that there's some 45.000 different companies out there running "The Internet" (just counting active AS numbers). 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 Sat Feb 12 05:42:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C3463A696B for ; Sat, 12 Feb 2011 05:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0Kt4kA7-VXI for ; Sat, 12 Feb 2011 05:42:25 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id B5B8C3A6892 for ; Sat, 12 Feb 2011 05:42:25 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 3050220AC4; Sat, 12 Feb 2011 08:42:43 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 12 Feb 2011 08:42:43 -0500 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=wM6TyKpQnLtMvLC/BCTS9+pG7x8=; b=rg6rHff+YL1HJCbSRQsL+8GSMUq4bn1j/ngVXCvgRHhfrCt1aR5UfmMQbA1fRHl5fgIySCxtVNDDA7CBuV+R6Rlz83OlMV8kDXI2HJ8rtGSQxIeat3AtyX6Zku77OA9td4U3tah5g1Eicr6cZJli3H7MdLnHEZliRiby96AGDSI= X-Sasl-enc: 2eXv85ScTClGpnkcuZgn1CN9bhUKwD//yR9lLDr+oih8 1297518162 Received: from 173-6-180-61.pools.spcsdns.net (unknown [173.6.180.61]) by mail.messagingengine.com (Postfix) with ESMTPA id 25AD84431B9; Sat, 12 Feb 2011 08:42:40 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110212130914.GZ44800@Space.Net> Date: Sat, 12 Feb 2011 08:42:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4E740826-FD8E-4702-85B6-DB4E2CB79345@network-heretics.com> References: <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <20110212130914.GZ44800@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1082) Cc: Daniel Roesen , "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 13:42:27 -0000 On Feb 12, 2011, at 8:09 AM, Gert Doering wrote: > On Tue, Feb 08, 2011 at 06:34:11PM -0500, Keith Moore wrote: >> I certainly get that impression from many of the participants >> here. There's definitely an ideology that use of 6to4 is somehow >> not legitimate and that it's therefore acceptable to sabotage it >> rather than to try to fix it. >=20 > This is completely missing the point. >=20 > 6to4 is already today frequently not working in a way that's not > possible to fix, because there's no way to figure out for a user=20 > who's 6to4 relay is breaking his *return* packets. If there were=20 > a central Internet authority that could order ISPs to properly run > their 6to4 relays, this might change, but there isn't. It's not really my wish to keep arguing about this. I've already = conceded that it's reasonable for implementations to disable 6to4 by = default. However, to respond to your points: There is no central Internet authority than can order ISPs to properly = run their v4 or v6 routers either. Somehow, (most) ISPs seem to try = to do that anyway. > Furthermore, 6to4 brokenness will go up due to the inevitable addition=20= > of CGN/LSNs due to IPv4 run-out. =20 That much I concede. If anything I think that 6to4 has two fatal flaws. One is that it was = intended to be a mechanism that would work without explicit ISP = involvement. This is, or should be, true for traffic going from one v4 = site to another (both ends using 2002: prefixes). But it's definitely = not true for traffic that requires use of relay routers. In hindsight = it's clear that ISPs throughout the network have to either maintain = relay routers themselves, or test their peers' relay routers to = determine whether the work and filter routes for those that don't. If = ISPs felt like 6to4 was part of their operational responsibility, I = think they could manage to do those things. But given that 6to4 wasn't = intended or designed to be part of their operational responsibility (for = instance, management of relay routers wasn't addressed), it's hard to = blame them for not wanting to fool with it.=20 The second flaw is that 6to4 simply wasn't designed to handle a scenario = where v4 addresses are extremely scarce and NATs are almost universally = required. The assumption was that any site needing to use 6to4 could at = least get one stable and global IPv4 address, until such a time as = native v6 service were widely available. > Nobody is advocating to go out and "filter proto 41, just for the sake > of it" or "mandate that Microsoft will remove 6to4 support from their > stacks" ("default-off" and "remove completely" are very much different > things for those that know what they want). Apparently some are filtering proto 41, some are filtering traffic to = relay router anycast addresses, and people have talked about = "deprecating" 6to4. "Default off" is less drastic than these, but it's = not the only idea that's been floated. >> The idea that the internet's only purpose is for users to get = "content" has always struck me as bizarre. =20 >=20 > It wasn't built that way, but that's what it is today. Not its only = purpose, > but that's where most of the money required to make it work is coming = from. I sometimes get the impression that operators often think in terms of = "how much money will it cost us (in support costs and lost customers) if = we break X"? I can see why they might think that way. But I don't = think this is an appropriate kind of analysis in an engineering = discussion, say, about what kind of technical mechanism should the = Internet use to address a particular problem. The reason is that the = effect of breaking some feature of the Internet isn't limited to the = network that broke it and its customers/users. For example, even when = only a relatively small percentage of networks were NATted, the = existence of NAT had a profound effect on applications throughout the = whole network. I also think that it's very difficult even for an operator, or anybody = really, to know what the effect will be of breaking some feature that = people are already using. An operator might have a good idea of how = many of its customers are using it, today. But it doesn't know how = valuable that feature is to those customers, nor how many customers are = planning to use something that requires that feature. (Even the = customers might not know those things, if they're not aware that their = applications are using the feature.) >> CGN is also going to make existing services break, likely causing = users to switch ISPs. >=20 > If "lots of users" are going to switch ISP to a new ISP without CGN - = what's > that ISP going to do, if all these new customers burn up his IPv4 = space? =20 > Cough up new IPv4 /8s, to keep "offering IPv4 Internet without CGN"? right... I think the result will be a lot of customer churn, at least = until it's widely understood that there are simply no more v4 addresses = to be had. > [..] >> But when operators start blaming 6to4 on problems that were actually = caused by operators, it's hard to see how they can find suitable = solutions. >=20 > Maybe you should remember that there's some 45.000 different companies=20= > out there running "The Internet" (just counting active AS numbers). of course I'm aware of that. =20 Keith From jbates@brightok.net Sat Feb 12 07:58:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745F03A6AAC for ; Sat, 12 Feb 2011 07:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvNEYwuxt6IX for ; Sat, 12 Feb 2011 07:58:54 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 7A3D73A6A16 for ; Sat, 12 Feb 2011 07:58:54 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p1CFx8mJ028344; Sat, 12 Feb 2011 09:59:08 -0600 (CST) Message-ID: <4D56AE42.7050109@brightok.net> Date: Sat, 12 Feb 2011 09:58:58 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Moore References: <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <20110212130914.GZ44800@Space.Net> <4E740826-FD8E-4702-85B6-DB4E2CB79345@network-heretics.com> In-Reply-To: <4E740826-FD8E-4702-85B6-DB4E2CB79345@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 15:58:55 -0000 On 2/12/2011 7:42 AM, Keith Moore wrote: > I sometimes get the impression that operators often think in terms of "how much money will it cost us (in support costs and lost customers) if we break X"? I can see why they might think that way. But I don't think this is an appropriate kind of analysis in an engineering discussion, say, about what kind of technical mechanism should the Internet use to address a particular problem. I think you'll find it more common for operators to think in realistic terms of what happens within the scope of the networks they control. I don't argue that there is something for the purity of overall engineering and making things work extremely well in a perfect plan. However, such engineering often discounts the scope of the operators and the individual problems faced by each in the real world environments. Networks aren't perfect (most protocol specifications aren't either, implementations even less so), most operators must make concessions to design based on the purchasing decisions or desires of others. We literally are given a bunch of gear (if lucky, we get to give input on what gear) and told to make it work. ISP networks are completely different environments from corporate networks (or educational), yet even within a class of network, the vendors, implementations, requirements, and designs are vastly different. If a technical mechanism won't be utilized by networks in the wild, or worse, networks will hurt such mechanisms, these are things to consider in an engineering scope. That is not to say such mechanisms aren't needed. If .01% is able to utilize 6to4 for some specific purpose that meets their needs (despite the problems), then the protocol specification was still needed. However, operators have to make appropriate decisions to keep the networks running with the tools they have, praying better tools are developed, and limit the damage caused by decisions which can't be avoided. Jack From moore@network-heretics.com Sat Feb 12 08:13:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD243A69A6 for ; Sat, 12 Feb 2011 08:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvkOUQQEfoaA for ; Sat, 12 Feb 2011 08:13:22 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id C05C43A695B for ; Sat, 12 Feb 2011 08:13:22 -0800 (PST) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 89CD1200F8; Sat, 12 Feb 2011 11:13:40 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 12 Feb 2011 11:13:40 -0500 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=jVFjiYeYcxfiR1EGfnXYOkGKBss=; b=GS6kh0bCVNOEuga4ePDgmrPwXKoGggFiTbWsLku97Kw7WS5kYSBfEfjDLZo2QGcPUCuTx+3jadM3DyzBlwZq8GkW0kqsSm80fKZ1tPCvhtMot6w9+3nzjVf363Wpv5TWeNAY/6XKAmpZisBTZlfQ9j54dCXc0JSh4wFC2yiKvHg= X-Sasl-enc: tLkZ4PUhp2+RYKvUimSccxtUVY192X/nSPfF2pG05XkA 1297527219 Received: from 173-6-180-61.pools.spcsdns.net (unknown [173.6.180.61]) by mail.messagingengine.com (Postfix) with ESMTPA id C438E445F98; Sat, 12 Feb 2011 11:13:37 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4D56AE42.7050109@brightok.net> Date: Sat, 12 Feb 2011 11:13:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3A1F95F6-AC48-42D7-8152-B5E7304AA3D8@network-heretics.com> References: <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com> <4D50490F.4070500@brightok.net> <9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com> <4D514A5E.5000404@brightok.net> <8F60964E-726A-4411-958C-09395034B83B@network-heretics.com> <20110208185049.GB28211@srv03.cluenet.de> <53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com> <0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com> <20110212130914.GZ44800@Space.Net> <4E740826-FD8E-4702-85B6-DB4E2CB79345@network-heretics.com> <4D56AE42.7050109@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: "v6ops@ietf.org" , Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 16:13:23 -0000 On Feb 12, 2011, at 10:58 AM, Jack Bates wrote: > On 2/12/2011 7:42 AM, Keith Moore wrote: >> I sometimes get the impression that operators often think in terms of = "how much money will it cost us (in support costs and lost customers) if = we break X"? I can see why they might think that way. But I don't = think this is an appropriate kind of analysis in an engineering = discussion, say, about what kind of technical mechanism should the = Internet use to address a particular problem. >=20 > I think you'll find it more common for operators to think in realistic = terms of what happens within the scope of the networks they control. I = don't argue that there is something for the purity of overall = engineering and making things work extremely well in a perfect plan. = However, such engineering often discounts the scope of the operators and = the individual problems faced by each in the real world environments. Well, most of my experience is as an applications developer and user. = So when I see things that operators have done (usually after having = spent a few days trying to diagnose the problem), I often find myself = asking "what the #$#@ were they thinking?". I can (and usually do) try = to imagine myself in their shoes, and sometimes I get an idea of why = they might have done what they did. But even then, it often seems that = they didn't really think about the consequences, or try to find a fix = for their problem that would minimize its adverse impact. =20 OTOH, I certainly agree that quite often, probably most of the time, the = design of network protocols doesn't really take operators' needs into = account. Keith From fred@cisco.com Sun Feb 13 09:06:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E653A6AC1 for ; Sun, 13 Feb 2011 09:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+ClAT64uvnK for ; Sun, 13 Feb 2011 09:06:20 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5310A3A6ABD for ; Sun, 13 Feb 2011 09:06:20 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPqeV02rR7Hu/2dsb2JhbACmAHOdZJoohV4EhQSGe4My X-IronPort-AV: E=Sophos;i="4.60,465,1291593600"; d="scan'208";a="661993728" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 13 Feb 2011 17:06:38 +0000 Received: from Freds-Computer.local ([10.21.118.158]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1DH6Tib004222; Sun, 13 Feb 2011 17:06:36 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sun, 13 Feb 2011 09:06:38 -0800 X-PGP-Universal: processed; by Freds-Computer.local on Sun, 13 Feb 2011 09:06:38 -0800 From: Fred Baker Date: Sun, 13 Feb 2011 09:06:26 -0800 To: "v6ops@ietf.org WG" Message-Id: <67F2AD16-302D-466A-943D-8B71F710F15B@cisco.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Agenda call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 17:06:21 -0000 The chairs will need to assemble an agenda for IETF-80 and publish it = pretty soon. Would those who want time on the meeting agenda please drop = a note to v6ops-chairs@tools.ietf.org? Each talk requires an internet draft that has been posted since IETF-79. Thanks.= From joelja@bogus.com Sun Feb 13 09:29:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A62C3A6A68 for ; Sun, 13 Feb 2011 09:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYLgv012q7c0 for ; Sun, 13 Feb 2011 09:29:22 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id DEA233A6ABD for ; Sun, 13 Feb 2011 09:29:21 -0800 (PST) Received: from [192.168.43.239] (m450536d0.tmodns.net [208.54.5.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p1DHTbK4067837 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sun, 13 Feb 2011 17:29:41 GMT (envelope-from joelja@bogus.com) Message-ID: <4D5814F9.3070800@bogus.com> Date: Sun, 13 Feb 2011 09:29:29 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPv6 Ops WG References: <4D4F6887.7050203@bogus.com> In-Reply-To: <4D4F6887.7050203@bogus.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sun, 13 Feb 2011 17:29:41 +0000 (UTC) Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 17:29:23 -0000 The halfway point has been reached, please get your feedback in by monday the 21st... On 2/6/11 7:35 PM, Joel Jaeggli wrote: > This announcement is to serve as the beginning of the WGLC for: > > draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 > > http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 > > WGLC runs from Monday Feb 7th to Monday Feb 21st. > > The 01 version of this document received a lot of good feedback on this > list which has been incorporated into this version of the draft. > > joelja > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Sun Feb 13 12:45:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4B63A6AEC for ; Sun, 13 Feb 2011 12:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.237 X-Spam-Level: X-Spam-Status: No, score=-103.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eftSQDTdKxiz for ; Sun, 13 Feb 2011 12:45:30 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id A44483A6AE3 for ; Sun, 13 Feb 2011 12:45:30 -0800 (PST) Received: by yie19 with SMTP id 19so2013234yie.31 for ; Sun, 13 Feb 2011 12:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ibyjOV+YzsmIPoGpG94PSxrY2OcHlbv3pEHyzj7VRw8=; b=IT+Enw4d5g9d8GaITH9ro44zFG8+17qJuy/+ZpG2MzB5KubUDFzMTG73CdGamAIAZJ oBgyc9aGQrVLXsmCsp61K9u46Okspnl7mBV8MHR6wP4as4lWMHspCViQKmPmFrRCaMXg /4mNEnS8v0sQSGvgEtm4oqhaS9naZag/2zuMo= 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=SgS+mWk7g9KpRbi211M45issIaJhKgLR2GpI77ZjL6H2+Kol9EZznJP8TU4GAWgeoW gOSsunSOyN0wmgv+n6Ljil9Y+WqYjag7QF6y/rQ8dE2cWE+ubPA21tYx6TjcSZplndIN EjhoSM44VLKYEtujnIjByrWCXdT6XLbcI+DxA= Received: by 10.150.50.10 with SMTP id x10mr3356016ybx.219.1297629951214; Sun, 13 Feb 2011 12:45:51 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id q31sm1164665yba.15.2011.02.13.12.45.49 (version=SSLv3 cipher=OTHER); Sun, 13 Feb 2011 12:45:50 -0800 (PST) Message-ID: <4D5842FC.8010501@gmail.com> Date: Mon, 14 Feb 2011 09:45:48 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joel Jaeggli References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> In-Reply-To: <4D5814F9.3070800@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 20:45:31 -0000 I think this is in good shape and ready to move forward. In fact it would be good to fast track it before June 8th. Regards Brian On 2011-02-14 06:29, Joel Jaeggli wrote: > The halfway point has been reached, please get your feedback in by > monday the 21st... > > > On 2/6/11 7:35 PM, Joel Jaeggli wrote: >> This announcement is to serve as the beginning of the WGLC for: >> >> draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 >> >> http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 >> >> WGLC runs from Monday Feb 7th to Monday Feb 21st. >> >> The 01 version of this document received a lot of good feedback on this >> list which has been incorporated into this version of the draft. >> >> joelja >> _______________________________________________ >> 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 gvandeve@cisco.com Mon Feb 14 03:38:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 071773A6CC2 for ; Mon, 14 Feb 2011 03:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOcNrxGaAIh1 for ; Mon, 14 Feb 2011 03:38:15 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8C24F3A6CC0 for ; Mon, 14 Feb 2011 03:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=1613; q=dns/txt; s=amsiport01001; t=1297683518; x=1298893118; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=pyWR16sgiqYfd/+HVr2bYTJ4f2hfSxH4uVjvC0uw3is=; b=cXqhLNBpTTbGBTLZ+zgKMcGyO7CNq7NSTIJ5s4tfOEikXNxdVg4xrrDy og/Hy/7cNqlGgNwjdIU6QJFRLfE3WhY6BOYYtqvKG0buQEEki/ZJ/1Ssh UpfSD8hWwO3RhTl+jDoP0nj4gttVxaK/4jpUM7xuTo+IFnBQVXHEpcxxc g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEEAJujWE2Q/khNgWdsb2JhbACmBhUBARYiJJ5zmlmFXgSPNw X-IronPort-AV: E=Sophos;i="4.60,468,1291593600"; d="scan'208";a="76203734" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2011 11:38:37 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p1EBcbbO031472; Mon, 14 Feb 2011 11:38:37 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 12:38:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Feb 2011 12:38:36 +0100 Message-ID: <4269EA985EACD24987D82DAE2FEC62E50316DDF1@XMB-AMS-101.cisco.com> In-Reply-To: <2B99A9A3-3FD5-42E2-B4A9-B7262737B80A@network-heretics.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Fwd: New Version Notification fordraft-troan-v6ops-6to4-to-historic-00 Thread-Index: AcvHtFPoEsxwVj/QQkioBiz9f+JUfwEhzEEg References: <20110207151430.44A393A6DD8@core3.amsl.com><20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com><4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com><4D5162E4.1020606@redpill-linpro.com> <2B99A9A3-3FD5-42E2-B4A9-B7262737B80A@network-heretics.com> From: "Gunter Van de Velde (gvandeve)" To: "Keith Moore" , "Cameron Byrne" X-OriginalArrivalTime: 14 Feb 2011 11:38:37.0779 (UTC) FILETIME=[B8533A30:01CBCC3B] Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification fordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 11:38:17 -0000 Would you have Data-points on this Keith? There are data-points on the brokenness of 6to4. (and yes, i am working with Brian also on making 6to4 experience better) G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Keith Moore Sent: 08 February 2011 18:19 To: Cameron Byrne Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification fordraft-troan-v6ops-6to4-to-historic-00 On Feb 8, 2011, at 11:32 AM, Cameron Byrne wrote: >> veryone* must play along. And that's simply not going to happen. >>=20 >> 6to4 was a fun little toy for people who wanted to experiment with IPv6. >> It is completely unsuitable to be Mr. John Q. Public's generic IPv6 >> internet connectivity. At this point in time, *real* IPv6 deployments is >> necessary, and 6to4 is just getting in the way. It's time to shelve it. >>=20 >=20 > This is the conclusion i believe you will hear from all network > operators that are really doing IPv6 now. I am not sure what it is > about tunneled IPv6 access that makes their creators so adamant about > it ... It's really native v4/v4v6/v6 or nothing on the real internet. > Why? Because people don't care about IP versions, and a tunnel is > never worth it. They care that facebook works. Everything else is > just pedantry. That is of course, completely false. And operators who persist in believing that are the source of the problem.=20 Keith _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From gvandeve@cisco.com Mon Feb 14 03:39:52 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91FC83A6CC4 for ; Mon, 14 Feb 2011 03:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bct9TS+GRn3P for ; Mon, 14 Feb 2011 03:39:51 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8046E3A6CC2 for ; Mon, 14 Feb 2011 03:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=311; q=dns/txt; s=amsiport01001; t=1297683614; x=1298893214; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=CGnetGHiJiWSOJ0Nkiqp+L0A+D/j39hUa99RNRW0UrI=; b=N1Z72+sVLT2ZQeVIFW/cPLkSsCUEMMX3xUuiMaFtpoCGIV7puYukWSXY wQ1Ojw0dErG5moy/V6BC0/9WzMZjlOxCXcqpp32uYrbsrseeaqaLafiOU QRb9NmYOgABBq0YpAXKGyH/mG1DG008L3FkRu8kV4GIeEHeKkRqZR4Rc1 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEEAJujWE2Q/khLgWdsb2JhbACmBhUBARYiJJ5zmlmFXgSPNw X-IronPort-AV: E=Sophos;i="4.60,468,1291593600"; d="scan'208";a="76203920" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2011 11:40:13 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p1EBeDJF025025; Mon, 14 Feb 2011 11:40:13 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 12:40:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Feb 2011 12:40:12 +0100 Message-ID: <4269EA985EACD24987D82DAE2FEC62E50316DDF3@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Fwd: New Version Notification fordraft-troan-v6ops-6to4-to-historic-00 Thread-Index: AcvHtk3+VtO3UJE9SgWad/TFTli7uQEhXu+A References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com><4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> From: "Gunter Van de Velde (gvandeve)" To: "Keith Moore" , "Ole Troan" X-OriginalArrivalTime: 14 Feb 2011 11:40:13.0433 (UTC) FILETIME=[F156DE90:01CBCC3B] Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification fordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 11:39:52 -0000 > it is difficult to see the motivation for anyone to run a relay router in the first place. To provide better service to their customers? Nah, no provider would want to do that... GV> :-) ... oversimplification here. There are providing 'better' service to people 'NOT' being their customer. G/ From gvandeve@cisco.com Mon Feb 14 03:53:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE273A6D09 for ; Mon, 14 Feb 2011 03:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8nNr5AkxOxA for ; Mon, 14 Feb 2011 03:53:12 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 066ED3A6956 for ; Mon, 14 Feb 2011 03:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=542; q=dns/txt; s=amsiport01001; t=1297684415; x=1298894015; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=GzqmKkQIsNIeX27QmtOZXpdedVXWnrx1pwRItkiEnHo=; b=mM4NRWmQ4v/FYuU2XttaqfgAhye0KqgdWntM0BFoGf/Y7Chj/gWjGupZ yPZ56cVdLJvsh9sFMdkq2r8yEXtDR7m+rsn41irDP+OoBPLpAvMANyHk/ iE+Hit/sjZGJpuLqj1xFfPbWa133AKTbbkXEwVbB1o2n/Ml8BFBgfXKnr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEEAB6nWE2Q/khMgWdsb2JhbACmBhUBARYiJJ5kmlmFXgSPNw X-IronPort-AV: E=Sophos;i="4.60,468,1291593600"; d="scan'208";a="76205423" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2011 11:53:34 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1EBrYuJ012206; Mon, 14 Feb 2011 11:53:34 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 12:53:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Feb 2011 12:53:32 +0100 Message-ID: <4269EA985EACD24987D82DAE2FEC62E50316DE01@XMB-AMS-101.cisco.com> In-Reply-To: <40E108BC-6709-4596-844B-B7E59F2643C7@network-heretics.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Fwd: New Version Notification fordraft-troan-v6ops-6to4-to-historic-00 Thread-Index: AcvH7Ua4q7vJ6FLkQ2aOik0Vk+6UaQEUFX5A References: <80C5E53A-04DA-4947-AEF9-BCF15DFA14C1@network-heretics.com><72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com><4D50490F.4070500@brightok.net><9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com><4D514A5E.5000404@brightok.net><8F60964E-726A-4411-958C-09395034B83B@network-heretics.com><20110208185049.GB28211@srv03.cluenet.de><53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com><54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com><20110208232327.GD13986@srv03.cluenet.de> <40E108BC-6709-4596-844B-B7E59F2643C7@network-heretics.com> From: "Gunter Van de Velde (gvandeve)" To: "Keith Moore" , "Daniel Roesen" X-OriginalArrivalTime: 14 Feb 2011 11:53:33.0975 (UTC) FILETIME=[CE7FE270:01CBCC3D] Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification fordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 11:53:13 -0000 <>start<> Meanwhile, I've also been trying to contribute to discussions about how to (a) gracefully phase out 6to4 in favor of native v6, and (b) allow 6to4 to continue working until that happens. I think it's much more appropriate to devote attention to those topics than to "who is to blame". But it's hard to do that while people are still trying to kill 6to4 prematurely. <>end<> It is not a question of who or what is to blame. Its a matter of getting the best Internet experience for the users of the environment. G/ From gvandeve@cisco.com Mon Feb 14 04:08:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D52D3A6D10 for ; Mon, 14 Feb 2011 04:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBEAVWx99CEk for ; Mon, 14 Feb 2011 04:08:00 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 4702C3A6D0B for ; Mon, 14 Feb 2011 04:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=2264; q=dns/txt; s=amsiport02001; t=1297685303; x=1298894903; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Bh+estkypy17GnfTaZKqAJvlVrHT6yQaVkyG+/0iSbg=; b=YvvViGYs7MMl0e0DxJTGxcRdPplC1vMFxFsAL5Yhmd8se9HzeYE1kR7/ JDJCQjRksr1zIzqUsrDy1xBYJxCveB+aTfy2gnzp4mWY1zNF8dfr8f2It yChuumOkfdAHzgmYDYXGDT1p2K8BFIa0Y24px6IJ3clTZOTwlq2g0AG6b E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEEALOpWE2Q/khNgWdsb2JhbACmBhUBARYiJJ5amlyFXgSPNw X-IronPort-AV: E=Sophos;i="4.60,469,1291593600"; d="scan'208";a="19122949" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 14 Feb 2011 12:08:22 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p1EC8MLW005679; Mon, 14 Feb 2011 12:08:22 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 13:08:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Feb 2011 13:08:10 +0100 Message-ID: <4269EA985EACD24987D82DAE2FEC62E50316DE17@XMB-AMS-101.cisco.com> In-Reply-To: <4E740826-FD8E-4702-85B6-DB4E2CB79345@network-heretics.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Fwd: New Version Notification fordraft-troan-v6ops-6to4-to-historic-00 Thread-Index: AcvKus1eKy3AKNHMRcS/UFGagF83yABg2SBw References: <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com><4D50490F.4070500@brightok.net><9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com><4D514A5E.5000404@brightok.net><8F60964E-726A-4411-958C-09395034B83B@network-heretics.com><20110208185049.GB28211@srv03.cluenet.de><53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com><54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com><0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com><20110212130914.GZ44800@Space.Net> <4E740826-FD8E-4702-85B6-DB4E2CB79345@network-heretics.com> From: "Gunter Van de Velde (gvandeve)" To: "Keith Moore" , "Gert Doering" X-OriginalArrivalTime: 14 Feb 2011 12:08:22.0226 (UTC) FILETIME=[DFF03B20:01CBCC3F] Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification fordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 12:08:02 -0000 <>start snip<> > Furthermore, 6to4 brokenness will go up due to the inevitable addition > of CGN/LSNs due to IPv4 run-out. =20 That much I concede. If anything I think that 6to4 has two fatal flaws. One is that it was intended to be a mechanism that would work without explicit ISP involvement. This is, or should be, true for traffic going from one v4 site to another (both ends using 2002: prefixes). But it's definitely not true for traffic that requires use of relay routers. In hindsight it's clear that ISPs throughout the network have to either maintain relay routers themselves, or test their peers' relay routers to determine whether the work and filter routes for those that don't. If ISPs felt like 6to4 was part of their operational responsibility, I think they could manage to do those things. But given that 6to4 wasn't intended or designed to be part of their operational responsibility (for instance, management of relay routers wasn't addressed), it's hard to blame them for not wanting to fool with it.=20 The second flaw is that 6to4 simply wasn't designed to handle a scenario where v4 addresses are extremely scarce and NATs are almost universally required. The assumption was that any site needing to use 6to4 could at least get one stable and global IPv4 address, until such a time as native v6 service were widely available. <>end snip<> GV> They are not flaws, it are attributes to the 6to4 technology that influence the usability of the technology for the quality of the users Internet experience. <>start snip<> > Nobody is advocating to go out and "filter proto 41, just for the sake > of it" or "mandate that Microsoft will remove 6to4 support from their=20 > stacks" ("default-off" and "remove completely" are very much different > things for those that know what they want). Apparently some are filtering proto 41, some are filtering traffic to relay router anycast addresses, and people have talked about "deprecating" 6to4. "Default off" is less drastic than these, but it's not the only idea that's been floated. <>end snip<> GV> We should do the right thing to improve the user experience on the Internet and not be religious to a single technology. G/ From gvandeve@cisco.com Mon Feb 14 04:21:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2319D3A6CAF for ; Mon, 14 Feb 2011 04:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuAJAt5fWEG8 for ; Mon, 14 Feb 2011 04:21:06 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EFF5A3A6CCF for ; Mon, 14 Feb 2011 04:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=520; q=dns/txt; s=amsiport01001; t=1297686089; x=1298895689; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=RxqHvYh2vTgMq0tbGIsEXtyhxEB9qpOrFb6r3QwLets=; b=fLD3jGGVrJhkMrYH14kCdi8TKPhlon2AH3jNMesGiRoNsaOSSfkytJx6 eJthRmizuovas0rfnQIdD98w1iZoewdeRQYZOgwrT42IwhaGP84jtFuDg qmeptnjHTc5gl8fPvJb58fA1jTDjOYbJT6ZWnEEGcJcs25hh7hTn22GOQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEEAPusWE2Q/khNgWdsb2JhbACmBhUBARYiJJ5XmmiFXgSPNw X-IronPort-AV: E=Sophos;i="4.60,469,1291593600"; d="scan'208";a="76208744" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2011 12:21:28 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p1ECLSKi008715; Mon, 14 Feb 2011 12:21:28 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); Mon, 14 Feb 2011 13:21:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Feb 2011 13:21:25 +0100 Message-ID: <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 Thread-Index: AcvHU17oWZIlNBpgTlmplfT0yUx01gE7Z4qw References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no><61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com><20110207175624.GA929@srv03.cluenet.de><403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> From: "Gunter Van de Velde (gvandeve)" To: "Keith Moore" , "Fred Baker (fred)" X-OriginalArrivalTime: 14 Feb 2011 12:21:28.0148 (UTC) FILETIME=[B4626940:01CBCC41] Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 12:21:08 -0000 Keith, <>start snip<> My problem with 6rd is that it's not something than an individual user who needs IPv6 can deploy independently of support from his ISP. =20 <>end snip<> Actually users could use that technology ...for example, if the 6rd ISP provider receives a /24 IPv6 prefix from his registry... then=20 the IPv4 address of the end-user can be added (24 + 32 =3D 56) then the end-user still has 8 bits available for subnetting. Its a case of use-case and implementation of the technology. G/ From moore@network-heretics.com Mon Feb 14 06:10:46 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC9A3A6D49 for ; Mon, 14 Feb 2011 06:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCtz2IAWfHlk for ; Mon, 14 Feb 2011 06:10:43 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id B448F3A6D4B for ; Mon, 14 Feb 2011 06:10:43 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 0ED29207FD; Mon, 14 Feb 2011 09:11:06 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 14 Feb 2011 09:11:06 -0500 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=ZrkLWhLToUtWRyWRyEsL8pG2it0=; b=tDoNhjO7zjEazo87x7bBp9ZsbVjlGhjL5UVQ0c7c5PLH8eNYqIta6HsUjhJey4vKE4Dje6PJR8gg51TEXSfJYoNFs01K1eDcoW51EZcpu3uXmp8oo1hy3HmFcwSBAveWoxnHAq5a88hhgCY+DCE+0/T8YFaLqppWkx+BprXUzI8= X-Sasl-enc: ylPutUX/keHzKII4t2lZMGjscx9jTNA0VJE8H0Z5gjbJ 1297692665 Received: from 173-6-180-61.pools.spcsdns.net (unknown [173.6.180.61]) by mail.messagingengine.com (Postfix) with ESMTPA id 8F9D94411AA; Mon, 14 Feb 2011 09:11:04 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> Date: Mon, 14 Feb 2011 09:11:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no><61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com><20110207175624.GA929@srv03.cluenet.de><403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> To: "Gunter Van de Velde (gvandeve)" X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 14:10:46 -0000 On Feb 14, 2011, at 7:21 AM, Gunter Van de Velde (gvandeve) wrote: > Keith, >=20 > <>start snip<> > My problem with 6rd is that it's not something than an individual user > who needs IPv6 can deploy independently of support from his ISP. =20 > <>end snip<> >=20 > Actually users could use that technology ...for example, if the 6rd = ISP > provider receives a /24 IPv6 prefix from his registry... then=20 > the IPv4 address of the end-user can be added (24 + 32 =3D 56) then = the > end-user still has 8 bits available for subnetting. You're missing the point I was trying to make, which is that, unlike = 6to4, users can't make use of 6rd without the ISP having explicit = support for it. I was aware that an ISP could give the user a /56 using 6rd. Not as = good as a /48, of course, but way better than a /64. Keith From moore@network-heretics.com Mon Feb 14 06:33:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA803A6D4A for ; Mon, 14 Feb 2011 06:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.904 X-Spam-Level: X-Spam-Status: No, score=-2.904 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDaQae9A2tc0 for ; Mon, 14 Feb 2011 06:33:20 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id 8DD1E3A6D48 for ; Mon, 14 Feb 2011 06:33:20 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 9D69D207AE; Mon, 14 Feb 2011 09:33:43 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 14 Feb 2011 09:33:43 -0500 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=IJy5+kYayIpoHDvPONmQpcSsUxc=; b=SjVhFifPoUNY9ebpkBNLi3GGs9ft0mr/nxvb28hKiBaYiBMiid8as7bOgPWMqtG5HWHJ++yKqr/F7k00tQEA4c/rmivUTzertF0oXT4gsf5DJa77j7Hy3KQgudMbyAmCmUPYTV3fmSxpPZ3wv9Kswh+/ksZQ4tUhgO/TSxwvmLQ= X-Sasl-enc: sm06ml9gImbZv7wGhm3/ikL/bpZyGIn9IpD1wdN4te5J 1297694022 Received: from 173-6-180-61.pools.spcsdns.net (unknown [173.6.180.61]) by mail.messagingengine.com (Postfix) with ESMTPA id 52B1B448F72; Mon, 14 Feb 2011 09:33:41 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-69--588244174 From: Keith Moore In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E50316DE17@XMB-AMS-101.cisco.com> Date: Mon, 14 Feb 2011 09:33:39 -0500 Message-Id: References: <72BF9A3D-62DE-4747-8F40-ADD742EE666E@cisco.com><4D50490F.4070500@brightok.net><9778D942-CB11-4781-83AE-76D2D9C2EB91@network-heretics.com><4D514A5E.5000404@brightok.net><8F60964E-726A-4411-958C-09395034B83B@network-heretics.com><20110208185049.GB28211@srv03.cluenet.de><53E2C3EC-5633-473F-A4C0-48AB54218FA1@network-heretics.com><54E900DC635DAB4DB7A6D799B3C4CD8E3674F8@PDAWM12B.ad.sprint.com><0808431C-61F3-4921-A2E0-F833AB8EB488@network-heretics.com><20110212130914.GZ44800@Space.Net> <4E740826-FD8E-4702-85B6-DB4E2CB79345@network-heretics.com> <4269EA985EACD24987D82DAE2FEC62E50316DE17@XMB-AMS-101.cisco.com> To: "Gunter Van de Velde (gvandeve)" X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, Daniel Roesen Subject: Re: [v6ops] Fwd: New Version Notification fordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 14:33:21 -0000 --Apple-Mail-69--588244174 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 14, 2011, at 7:08 AM, Gunter Van de Velde (gvandeve) wrote: >=20 > GV> We should do the right thing to improve the user experience on the > Internet and not be religious to a single technology. I certainly agree about not being religious to a single technology. =20 I also agree in principle with the idea of improving the user experience = of the Internet. But there are several problems with interpreting that = idea. Probably the biggest one is that something that improves the = user's experience in the short term may do harm to the user's experience = in the long term. NAT, for example, allowed users to run more than one = computer from the same connection, but also crippled the Internet's = ability to run certain kinds of applications, and thereby impaired the = users' ability to experience those applications. Another problem is = that many Internet applications don't exist to enhance a "user's = experience" as they're not aimed at end users, but they can still be = quite valuable. A third is that thinking only in terms of "improving = the user's experience" can encourage the "all users are alike" = mentality, and/or the "the Internet will always be like it is now" = mentality, both of which lead to incorrect analysis. I'm pretty convinced that the best way to improve users' experience of = the Internet in the long term is to keep the Internet flexible enough to = handle a wide variety of applications, so that it can serve a wide = variety of users, and bring a wide variety of new applications to users. = =20 Keith p.s. What originally motivated me to work on IPv6 in general, 10+ years = ago when I was an Applications Area Director, was the realization that = NATs were crippling the IPv4 network and limiting the kinds of = applications that users could run. 6to4 was just a mechanism that I = hoped would further this goal. =20 --Apple-Mail-69--588244174 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

GV> We should = do the right thing to improve the user experience on the
Internet and = not be religious to a single = technology.

I certainly agree about = not being religious to a single technology. =   

I also agree in principle with the = idea of improving the user experience of the Internet.   But there = are several problems with interpreting that idea.  Probably the = biggest one is that something that improves the user's experience in the = short term may do harm to the user's experience in the long term. =  NAT, for example, allowed users to run more than one computer from = the same connection, but also crippled the Internet's ability to run = certain kinds of applications, and thereby impaired the users' ability = to experience those applications.   Another problem is that many = Internet applications don't exist to enhance a "user's experience" as = they're not aimed at end users, but they can still be quite valuable. =  A third is that thinking only in terms of "improving the user's = experience" can encourage the "all users are alike" mentality, and/or = the "the Internet will always be like it is now" mentality, both of = which lead to incorrect analysis.

I'm pretty = convinced that the best way to improve users' experience of the Internet = in the long term is to keep the Internet flexible enough to handle a = wide variety of applications, so that it can serve a wide variety of = users, and bring a wide variety of new applications to users. =  

Keith

p.s. &= nbsp;What originally motivated me to work on IPv6 in general, 10+ years = ago when I was an Applications Area Director, was the realization that = NATs were crippling the IPv4 network and limiting the kinds of = applications that users could run.  6to4 was just a mechanism that = I hoped would further this goal. =  

= --Apple-Mail-69--588244174-- From townsley@cisco.com Mon Feb 14 06:33:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EADEB3A6D67 for ; Mon, 14 Feb 2011 06:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lL5TQ++LBrx for ; Mon, 14 Feb 2011 06:33:33 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1E0703A6D64 for ; Mon, 14 Feb 2011 06:33:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=6027; q=dns/txt; s=amsiport01001; t=1297694036; x=1298903636; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=9egizws241S2Hj4PT/fn7J7M2luDbzeV6PcPVMO3Inw=; b=g4HZlBoK1udmZmc6YiCfiOZ2SMWe9gY3Od03zPlYBRa+E24Eet6h9zyE Gs7VpNJg3nXWW9++IjxYsERkHLplRQih0jvd/SM3hNHHVDMxDReCPDhU1 N3uD2ZFk8f8MGou6HBS3Q5d+Y9e+d+FJbxA7KPKo2C8ukNhs1L8JDG9yd Q=; X-IronPort-AV: E=Sophos;i="4.60,469,1291593600"; d="scan'208,217";a="76227000" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2011 14:33:55 +0000 Received: from ams-townsley-8711.cisco.com (ams-townsley-8711.cisco.com [10.55.233.226]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p1EEXtb9005402; Mon, 14 Feb 2011 14:33:55 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-107--588221048 From: Mark Townsley In-Reply-To: Date: Mon, 14 Feb 2011 15:34:02 +0100 Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no><61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com><20110207175624.GA929@srv03.cluenet.de><403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 14:33:35 -0000 --Apple-Mail-107--588221048 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 14, 2011, at 3:11 PM, Keith Moore wrote: > You're missing the point I was trying to make, which is that, unlike = 6to4, users can't make use of 6rd without the ISP having explicit = support for it. It's a point that you can get rather quickly from the first sentence in = the abstract of RFC 5969, and the following sentence in second paragraph = of the introduction: "This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a service provider's IPv4 network infrastructure."=20 "By using the SP's IPv6 prefix, the operational domain of 6rd is = limited to the SP network and is under its direct control." 6rd uses technology that looks like 6to4, but in no way is it intended = for you or any other user to make use of without some ISP supporting it. = It's a lot like native IPv6 in that regard. - Mark > I was aware that an ISP could give the user a /56 using 6rd. Not as = good as a /48, of course, but way better than a /64. >=20 > Keith >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-107--588221048 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
You're missing the point = I was trying to make, which is that, unlike 6to4, users can't make use = of 6rd without the ISP having explicit support for = it.

It's a point that = you can get rather quickly from the first sentence in the abstract of = RFC 5969, and the following sentence in second paragraph of the = introduction:

  =
 "This document specifies an automatic tunneling mechanism tailored to
   advance deployment of IPv6 to end users via a service =
provider's IPv4
   network infrastructure." 

  =
 "By using the SP's =
IPv6 prefix, the operational domain of 6rd is limited to the =
SP
   network and is =
under its direct control."

6rd uses technology that looks like 6to4, but in no way is it =
intended for you or any other user to make use of without some ISP =
supporting it. It's a lot like native IPv6 in that =
regard.

- =
Mark

I was aware that an ISP could give the user a /56 = using 6rd.  Not as good as a /48, of course, but way better than a = /64.

Keith


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

= --Apple-Mail-107--588221048-- From ichiroumakino@gmail.com Mon Feb 14 06:40:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF083A6D56 for ; Mon, 14 Feb 2011 06:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwNk2V0PMGsc for ; Mon, 14 Feb 2011 06:40:38 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id D234A3A6D48 for ; Mon, 14 Feb 2011 06:40:37 -0800 (PST) Received: by wwi17 with SMTP id 17so1953517wwi.1 for ; Mon, 14 Feb 2011 06:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=rokPpdB2W4Yu0C1ofQyUsTX+BJWoQkq03Mjk5rswyhg=; b=fDmVyz3G0KzgCuYZ/kAOGz79BXs3Hs24hDJp5F74XYIR36GLG4OX6D9DgWn9oioaPR 3CTAA97S+MgE3SwNd2KDKKtO1oga0RR3l7gkVgyET4WO4YqK6bW8BSlsja6e8uy8Mawd lEjTc8MGpUHVpwCAr3ARL4Rmu+5hujUq0SLfA= 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=xL0f6xgeRm3A8F4wc4lj2m7sBJiiY8+yKmfuGXGmANx5D60Gp7ye0WX1YRFCkvcq9s GZx5ibcAu/ZbrPiVHg6NgmQd/GNGAXqrY4kIq/Z3QqcXnV4jnnkEKgh50ynLkAWhZX1X fgQdmEfbToz9pSEyATXbPS0Je8cxrxtzumhsk= Received: by 10.227.69.198 with SMTP id a6mr2573993wbj.127.1297694460195; Mon, 14 Feb 2011 06:41:00 -0800 (PST) Received: from dhcp-osl-vl300-64-103-53-238.cisco.com (dhcp-osl-vl300-64-103-53-238.cisco.com [64.103.53.238]) by mx.google.com with ESMTPS id o6sm1955175wbo.21.2011.02.14.06.40.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Feb 2011 06:40:59 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 14 Feb 2011 15:40:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no><61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com><20110207175624.GA929@srv03.cluenet.de><403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 14:40:39 -0000 [...] (assuming we are talking about residential users here) > I was aware that an ISP could give the user a /56 using 6rd. Not as = good as a /48, of course, but way better than a /64. does that imply that a /40 or a /32 is even better? (and a /0 is the = best of all. ;-)) why is a /48 better than a /56? if this were to be true it would force = SPs into competing on whom could give users the most amount of (wasted) = address space... cheers, Ole= From moore@network-heretics.com Mon Feb 14 07:13:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9023A6D64 for ; Mon, 14 Feb 2011 07:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.415 X-Spam-Level: X-Spam-Status: No, score=-3.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XM5aoQ5RE0HL for ; Mon, 14 Feb 2011 07:13:19 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id 7B1283A6D63 for ; Mon, 14 Feb 2011 07:13:19 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 639C4208C5; Mon, 14 Feb 2011 10:13:42 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 14 Feb 2011 10:13:42 -0500 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=nv5HYQnwUn/wl60jFwO49Btv+2k=; b=AqyrvGcXmvsm7pP1YSfmwSz81qhye1pIkl9SjCtwqjy3SiRO/pDzkMyryV4nDuzTluEkODkU16tEWkgJp5s9Hg2GWaUjYiV3EhY/pR50eGJc9RvuT1eNiDe8jYNqgAO/gqKKYPiMlCZedmGXvXYpotJr4yrmf9QVVtvXQPJRnYk= X-Sasl-enc: Y/RoROKtTEoT6Uo7zWvlj1iG6EytvMX6lRYKB1ZQoAjJ 1297696421 Received: from 173-6-180-61.pools.spcsdns.net (unknown [173.6.180.61]) by mail.messagingengine.com (Postfix) with ESMTPA id F06604405C2; Mon, 14 Feb 2011 10:13:40 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Mon, 14 Feb 2011 10:13:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no><61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com><20110207175624.GA929@srv03.cluenet.de><403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> To: Ole Troan X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 15:13:20 -0000 On Feb 14, 2011, at 9:40 AM, Ole Troan wrote: > (assuming we are talking about residential users here) >=20 >> I was aware that an ISP could give the user a /56 using 6rd. Not as = good as a /48, of course, but way better than a /64. >=20 > does that imply that a /40 or a /32 is even better? (and a /0 is the = best of all. ;-)) of course not. =20 > why is a /48 better than a /56? if this were to be true it would force = SPs into competing on whom could give users the most amount of (wasted) = address space... For the vast majority of residential users, a /56 is as good as a /48. = Even a /64 would probably be good enough, assuming that the market would = produce clever routers that could handle hosts on each of multiple links = within a single /64 and implement a ND proxy to let the hosts talk to = each other. (It appears that there will be multiple L2 technologies = used in home automation networks.) However, if an ISP relies on 6rd as its mechanism for routing v6 = internally through much of its network, so that it can only offer a /56 = to its "commodity service" customers, that's going to impair the ability = of some of those customers to use the Internet. And that might lead to = a demand for NAT in IPv6, and that (as we know from experience) would do = a great deal of harm. I can understand why an ISP might want to = cripple "residential" service in hopes of getting those customers to pay = for more expensive service (like the salesman who tried to sell me a T1 = line to my house last week because they couldn't offer me DSL without = port blocking). But many valuable organizations are going to be stuck = with "residential" service only and are going to need to subnet. Keith p.s. Personally I think that allocating 64 bits to an interface = identifier, and wiring that into the v6 architecture, were very = shortsighted. I think there will be a number of important cases where = sites will need to subnet past /64. I'm also one of those people who = wishes that the IPng people had tried harder to find a way to make = variable length addresses work. But those are water under the bridge. From ichiroumakino@gmail.com Mon Feb 14 07:25:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1092E3A6D48 for ; Mon, 14 Feb 2011 07:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQXotX-54lrx for ; Mon, 14 Feb 2011 07:25:12 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id BAD713A6BCD for ; Mon, 14 Feb 2011 07:25:11 -0800 (PST) Received: by wwa36 with SMTP id 36so4893751wwa.13 for ; Mon, 14 Feb 2011 07:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=fWLU7FLXAA/iEgZwHWBFZvaEyDqxLmcqjRTT0xU8tw0=; b=LtRwHscnpn9K4mqCRHAH/Gh36hXg8ufSs4GvxRiZZsR4sbxUZrXxvh48RWu4hRA+I3 2Q7QArHBf6kZqEy0v9EZGGqjVLilXOldnOzC7hc9y+4tXRQGzPVHEi/CCGjFPXbeKHRh 14CZHQetsAvy7uE/5mpygrmKqLZXm2nELUuts= 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=iB5fwoZhOo3arqzJb+YhohIJk95fJtgJAM4mFsCvKkcqPe8mGAjMmMnOvN/JHvlFET B7hWAR6vBu1WUSVR3OpYmfxnDBXWCb2QiQ7UU3iJxt3CZvPXpj7xChNS7QzTxovw+skD vZRFeArSd9As44tubFZMPza3nr9A3vYrKrqYk= Received: by 10.216.59.143 with SMTP id s15mr801973wec.49.1297697134196; Mon, 14 Feb 2011 07:25:34 -0800 (PST) Received: from dhcp-osl-vl300-64-103-53-238.cisco.com (dhcp-osl-vl300-64-103-53-238.cisco.com [64.103.53.238]) by mx.google.com with ESMTPS id b54sm893070wer.45.2011.02.14.07.25.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Feb 2011 07:25:32 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 14 Feb 2011 16:25:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no><61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com><20110207175624.GA929@srv03.cluenet.de><403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 15:25:15 -0000 Keith, >> (assuming we are talking about residential users here) >>=20 >>> I was aware that an ISP could give the user a /56 using 6rd. Not as = good as a /48, of course, but way better than a /64. >>=20 >> does that imply that a /40 or a /32 is even better? (and a /0 is the = best of all. ;-)) >=20 > of course not. =20 >=20 >> why is a /48 better than a /56? if this were to be true it would = force SPs into competing on whom could give users the most amount of = (wasted) address space... >=20 > For the vast majority of residential users, a /56 is as good as a /48. = Even a /64 would probably be good enough, assuming that the market = would produce clever routers that could handle hosts on each of multiple = links within a single /64 and implement a ND proxy to let the hosts talk = to each other. (It appears that there will be multiple L2 technologies = used in home automation networks.) >=20 > However, if an ISP relies on 6rd as its mechanism for routing v6 = internally through much of its network, so that it can only offer a /56 = to its "commodity service" customers, that's going to impair the ability = of some of those customers to use the Internet. And that might lead to = a demand for NAT in IPv6, and that (as we know from experience) would do = a great deal of harm. I can understand why an ISP might want to = cripple "residential" service in hopes of getting those customers to pay = for more expensive service (like the salesman who tried to sell me a T1 = line to my house last week because they couldn't offer me DSL without = port blocking). But many valuable organizations are going to be stuck = with "residential" service only and are going to need to subnet. all the mechanisms that depend on encoding the tunnel endpoint address = in the IPv6 address suffers to some degree of limitations of what end = user network prefix can be used. you can of course deliver a "native" IPv6 prefix over any of these = mechanisms too. e.g. running DHCPv6 PD on top of 6rd or 6to4. we are no longer talking about networks that 6rd or 6to4 was designed = for. /48 or /56 in these cases are the difference between infinity or = infinity + 1. > p.s. Personally I think that allocating 64 bits to an interface = identifier, and wiring that into the v6 architecture, were very = shortsighted. I think there will be a number of important cases where = sites will need to subnet past /64. I'm also one of those people who = wishes that the IPng people had tried harder to find a way to make = variable length addresses work. But those are water under the bridge. indeed. technically it is little problem changing (already works with = DHCPv6). but, this is largely politically motivated. design IPv6 so that = end-users get at least a /64 and aren't forced to do NAT. cheers, Ole From moore@network-heretics.com Mon Feb 14 07:35:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0933A6D5E for ; Mon, 14 Feb 2011 07:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBN+VcpT4HR5 for ; Mon, 14 Feb 2011 07:35:07 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id F2AF53A6D6E for ; Mon, 14 Feb 2011 07:35:06 -0800 (PST) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 2838F202CD; Mon, 14 Feb 2011 10:35:30 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 14 Feb 2011 10:35:30 -0500 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=T5O8fX+vjw3v2TrRVb6IvjdoI6Y=; b=OXK0gq53Fv3se77W22tA+9oVbV3d9FK3l0UN8h6kUhdCek9mYdgXKfXHfLng+9+1ChAovaSJs6YElRtdNFj9647sDl55Glq/7Z7bGv3WHcAyZFTgXngjrFQbwj4NCBv4l28s48RSpAY9GwvGO+Z7p8zgO9LUxfzjf0xJONnuUSU= X-Sasl-enc: rZm2Ckqph1ej4lxFYQR4rQTVk5T04V40w6XrHIg1OT8Q 1297697729 Received: from 173-6-180-61.pools.spcsdns.net (unknown [173.6.180.61]) by mail.messagingengine.com (Postfix) with ESMTPA id CFBD7449001; Mon, 14 Feb 2011 10:35:28 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Mon, 14 Feb 2011 10:35:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no><61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com><20110207175624.GA929@srv03.cluenet.de><403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> To: Ole Troan X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 15:35:10 -0000 > all the mechanisms that depend on encoding the tunnel endpoint address = in the IPv6 address suffers to some degree of limitations of what end = user network prefix can be used. Agree. > you can of course deliver a "native" IPv6 prefix over any of these = mechanisms too. e.g. running DHCPv6 PD on top of 6rd or 6to4. DHCPv6 doesn't let you route a longer prefix to a customer over 6rd. =20 > /48 or /56 in these cases are the difference between infinity or = infinity + 1. Not so. It's not like the customer really gets to have = 2^(128-prefix_length) hosts or anywhere close to that. As long as = we're still stuck with subnetting on bit boundaries, a lot of space will = continue be wasted. And there are a number of places where the = assumption of max_prefix_length =3D=3D 64 is wired into IPv6 protocols = and code. >> p.s. Personally I think that allocating 64 bits to an interface = identifier, and wiring that into the v6 architecture, were very = shortsighted. I think there will be a number of important cases where = sites will need to subnet past /64. I'm also one of those people who = wishes that the IPng people had tried harder to find a way to make = variable length addresses work. But those are water under the bridge. >=20 > indeed. technically it is little problem changing (already works with = DHCPv6). but, this is largely politically motivated. design IPv6 so that = end-users get at least a /64 and aren't forced to do NAT. One person's "political motivations" are another person's "making the = net work well" and another person's "business need". =20 Keith From ichiroumakino@gmail.com Mon Feb 14 07:43:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0AFD3A6D80 for ; Mon, 14 Feb 2011 07:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcmwIWeZBQfa for ; Mon, 14 Feb 2011 07:43:41 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 7FB873A6D6E for ; Mon, 14 Feb 2011 07:43:41 -0800 (PST) Received: by wyf23 with SMTP id 23so5186740wyf.31 for ; Mon, 14 Feb 2011 07:44:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=rbZg/PNlv2yJMrM75PRbTySPI+Bo6RkCvljrjeeRW50=; b=twsoRAXx9VJMVL1jP4OfYgcQ8xI0de6UOyn0Pvf0+LgP9OB7sCjoa3jBDYC5XJUTIu MkSx8vCug2TRIPP+9JgiZ+honj9WWrDtlKJ90/h6vm674BLmv6PdJ9KgufYGIcQer7Nd LypVPG0bEf+RZ9WOxRRhi0B/ncesEZVm6dfZw= 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=qoqC7aEkTwdTfJ7DywlUoPS9B8ceuzrZlqQQITruu2jG/fpCyf2yEHmteRm/vD20oC gI2rWt2QLkLXfbkOzh+DeRTkQHFtsKkCIZW0Cd+plsxrX9n77btMdMYHdCk3BHc5KHF2 MrhCd+1s4JWs7iho8RRLLQtPXHXAng4mSRMoU= Received: by 10.227.156.207 with SMTP id y15mr2665730wbw.38.1297698243887; Mon, 14 Feb 2011 07:44:03 -0800 (PST) Received: from dhcp-osl-vl300-64-103-53-238.cisco.com (dhcp-osl-vl300-64-103-53-238.cisco.com [64.103.53.238]) by mx.google.com with ESMTPS id f27sm2005453wbf.1.2011.02.14.07.44.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Feb 2011 07:44:02 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 14 Feb 2011 16:44:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E67599D-792E-4E00-8154-6580B5FEE1F4@employees.org> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no><61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com><20110207175624.GA929@srv03.cluenet.de><403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 15:43:43 -0000 >> you can of course deliver a "native" IPv6 prefix over any of these = mechanisms too. e.g. running DHCPv6 PD on top of 6rd or 6to4. >=20 > DHCPv6 doesn't let you route a longer prefix to a customer over 6rd. =20= you run DHCPv6 PD on top of the automatic tunnel and delegate native = prefixes. in that case {6rd,ISATAP,6to4} is just used for transport. = can't remember if Fred Templin ever documented this mode or not. >> /48 or /56 in these cases are the difference between infinity or = infinity + 1. >=20 > Not so. It's not like the customer really gets to have = 2^(128-prefix_length) hosts or anywhere close to that. As long as = we're still stuck with subnetting on bit boundaries, a lot of space will = continue be wasted. And there are a number of places where the = assumption of max_prefix_length =3D=3D 64 is wired into IPv6 protocols = and code. no, but the user would be able to get 2^8 links or 2^8-1 if the CPE took = one for itself. I would have thought that an end user requiring more than 2^8-1 number = of links, with room for 2^64 number of hosts each, would have to "talk" = to his ISP anyway... >>> p.s. Personally I think that allocating 64 bits to an interface = identifier, and wiring that into the v6 architecture, were very = shortsighted. I think there will be a number of important cases where = sites will need to subnet past /64. I'm also one of those people who = wishes that the IPng people had tried harder to find a way to make = variable length addresses work. But those are water under the bridge. >>=20 >> indeed. technically it is little problem changing (already works with = DHCPv6). but, this is largely politically motivated. design IPv6 so that = end-users get at least a /64 and aren't forced to do NAT. >=20 > One person's "political motivations" are another person's "making the = net work well" and another person's "business need". indeed. in any case I don't think the fact that 6to4 guarantees a /48 (but with = patchy connectivity ;-)), justifies that mechanism with all its = shortcomings over IPv6 access (6rd or native) which may give the user a = /56. or whatever the SP decides for its default, vanilla service. (I = would much rather have multi-homing than larger than /56 in my home). cheers, Ole From moore@network-heretics.com Mon Feb 14 08:02:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1733A6D20 for ; Mon, 14 Feb 2011 08:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX4F10pTipqL for ; Mon, 14 Feb 2011 08:02:30 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id ADA253A6C0A for ; Mon, 14 Feb 2011 08:02:30 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id BE49D207A0; Mon, 14 Feb 2011 11:02:53 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 14 Feb 2011 11:02:53 -0500 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=/538bMtItXbAAhhkqwrZbFdCZcU=; b=YmigxrohJmGd9feRVC1Wus6+2eBQj2+O8dmSWkwiON3a8PBsjUuPmXpxtLtN9VDqQ3VJhgTtt28Wsx9ElbOddpZsXv0VG3pDzsu7DIjyZL6iOQ2qfIrm7wVrI3CKUFIp8lIeaScdp2niKeR6Ews2SrBBIoG4yya2+OgJfNfznnA= X-Sasl-enc: BtE8q4p8wpMKRGVnWFo+pq5D10zo3sm3xuo2pGMYYbY0 1297699372 Received: from 173-6-180-61.pools.spcsdns.net (unknown [173.6.180.61]) by mail.messagingengine.com (Postfix) with ESMTPA id 6775B444077; Mon, 14 Feb 2011 11:02:52 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <2E67599D-792E-4E00-8154-6580B5FEE1F4@employees.org> Date: Mon, 14 Feb 2011 11:02:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8A675ADE-8D8B-405E-A852-EF4F6406FCA4@network-heretics.com> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no><61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com><20110207175624.GA929@srv03.cluenet.de><403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> <2E67599D-792E-4E00-8154-6580B5FEE1F4@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 16:02:32 -0000 On Feb 14, 2011, at 10:44 AM, Ole Troan wrote: >>> you can of course deliver a "native" IPv6 prefix over any of these = mechanisms too. e.g. running DHCPv6 PD on top of 6rd or 6to4. >>=20 >> DHCPv6 doesn't let you route a longer prefix to a customer over 6rd. =20= >=20 > you run DHCPv6 PD on top of the automatic tunnel and delegate native = prefixes. in that case {6rd,ISATAP,6to4} is just used for transport. = can't remember if Fred Templin ever documented this mode or not. >=20 >>> /48 or /56 in these cases are the difference between infinity or = infinity + 1. >>=20 >> Not so. It's not like the customer really gets to have = 2^(128-prefix_length) hosts or anywhere close to that. As long as = we're still stuck with subnetting on bit boundaries, a lot of space will = continue be wasted. And there are a number of places where the = assumption of max_prefix_length =3D=3D 64 is wired into IPv6 protocols = and code. >=20 > no, but the user would be able to get 2^8 links or 2^8-1 if the CPE = took one for itself. > I would have thought that an end user requiring more than 2^8-1 number = of links, with room for 2^64 number of hosts each, would have to "talk" = to his ISP anyway... And that's why I agree that for most users /56 is as good as /48. Though I keep thinking of situations where somebody needs to string = together a lot of hosts on short notice and/or a tight budget. Disaster = relief is one such scenario; conferences are another. They're rare = situations, but it's nice if the network can support them without having = to get people at an ISP explicitly involved. >>>> p.s. Personally I think that allocating 64 bits to an interface = identifier, and wiring that into the v6 architecture, were very = shortsighted. I think there will be a number of important cases where = sites will need to subnet past /64. I'm also one of those people who = wishes that the IPng people had tried harder to find a way to make = variable length addresses work. But those are water under the bridge. >>>=20 >>> indeed. technically it is little problem changing (already works = with DHCPv6). but, this is largely politically motivated. design IPv6 so = that end-users get at least a /64 and aren't forced to do NAT. >>=20 >> One person's "political motivations" are another person's "making the = net work well" and another person's "business need". >=20 > indeed. >=20 > in any case I don't think the fact that 6to4 guarantees a /48 (but = with patchy connectivity ;-)), justifies that mechanism with all its = shortcomings over IPv6 access (6rd or native) which may give the user a = /56. or whatever the SP decides for its default, vanilla service. (I = would much rather have multi-homing than larger than /56 in my home). The point I was making was that 6to4 and 6rd serve different use cases. = Neither one subsumes the need for the other. Keith From dr@cluenet.de Mon Feb 14 08:32:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4AB3A6D4C for ; Mon, 14 Feb 2011 08:32:16 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsXV4DVGLGMF for ; Mon, 14 Feb 2011 08:32:15 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 3A3263A6D43 for ; Mon, 14 Feb 2011 08:32:15 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id B0D4D108096; Mon, 14 Feb 2011 17:32:36 +0100 (CET) Date: Mon, 14 Feb 2011 17:32:36 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110214163236.GA9513@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 16:32:16 -0000 On Mon, Feb 14, 2011 at 10:13:39AM -0500, Keith Moore wrote: > Even a /64 would probably be good enough, assuming that the market > would produce clever routers that could handle hosts on each of > multiple links within a single /64 and implement a ND proxy to let > the hosts talk to each other. That's not clever, that's an ugly hack we certainly want to avoid. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From Fred.L.Templin@boeing.com Mon Feb 14 08:49:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42EC73A6A57 for ; Mon, 14 Feb 2011 08:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.12 X-Spam-Level: X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5BlvwQAaNgJ for ; Mon, 14 Feb 2011 08:48:56 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 576A53A6A0F for ; Mon, 14 Feb 2011 08:48:56 -0800 (PST) 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 p1EGn9Bs026970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Feb 2011 08:49:10 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1EGn9AY025365; Mon, 14 Feb 2011 10:49:09 -0600 (CST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1EGn9JF025349 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 14 Feb 2011 10:49:09 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Mon, 14 Feb 2011 08:49:09 -0800 From: "Templin, Fred L" To: Ole Troan , Keith Moore Date: Mon, 14 Feb 2011 08:49:08 -0800 Thread-Topic: [v6ops] Fwd: New VersionNotificationfordraft-troan-v6ops-6to4-to-historic-00 Thread-Index: AcvMXhvTqa2kuHgdTlOeXpzv2RPwRwAB4W/g Message-ID: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no> <61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com><20110207175624. GA929@srv03.cluenet.de><403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com><4269EA985EACD24987D82 DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> <2E67599D-792E-4E00-8154-6580B5FEE1F4@employees.org> In-Reply-To: <2E67599D-792E-4E00-8154-6580B5FEE1F4@employees.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: IPv6 Operations Subject: Re: [v6ops] Fwd: New VersionNotificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 16:49:00 -0000 Hi Ole, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Ole Troan > Sent: Monday, February 14, 2011 7:44 AM > To: Keith Moore > Cc: IPv6 Operations > Subject: Re: [v6ops] Fwd: New=20 > VersionNotificationfordraft-troan-v6ops-6to4-to-historic-00 >=20 > >> you can of course deliver a "native" IPv6 prefix over any=20 > of these mechanisms too. e.g. running DHCPv6 PD on top of 6rd or 6to4. > >=20 > > DHCPv6 doesn't let you route a longer prefix to a customer=20 > over 6rd. =20 >=20 > you run DHCPv6 PD on top of the automatic tunnel and delegate=20 > native prefixes. in that case {6rd,ISATAP,6to4} is just used=20 > for transport. can't remember if Fred Templin ever=20 > documented this mode or not. But of course: https://datatracker.ietf.org/doc/draft-templin-intarea-vet/ In terms of plain-old ISATAP, RFC4861 tells that DHCPv6 is available when the M flag is set in RAs, and RFC5214 states that RAs are processed as specificed in RFC4861. Thanks - Fred fred.l.templin@boeing.com > >> /48 or /56 in these cases are the difference between=20 > infinity or infinity + 1. > >=20 > > Not so. It's not like the customer really gets to have=20 > 2^(128-prefix_length) hosts or anywhere close to that. As=20 > long as we're still stuck with subnetting on bit boundaries,=20 > a lot of space will continue be wasted. And there are a=20 > number of places where the assumption of max_prefix_length =3D=3D=20 > 64 is wired into IPv6 protocols and code. >=20 > no, but the user would be able to get 2^8 links or 2^8-1 if=20 > the CPE took one for itself. > I would have thought that an end user requiring more than=20 > 2^8-1 number of links, with room for 2^64 number of hosts=20 > each, would have to "talk" to his ISP anyway... >=20 > >>> p.s. Personally I think that allocating 64 bits to an=20 > interface identifier, and wiring that into the v6=20 > architecture, were very shortsighted. I think there will be=20 > a number of important cases where sites will need to subnet=20 > past /64. I'm also one of those people who wishes that the=20 > IPng people had tried harder to find a way to make variable=20 > length addresses work. But those are water under the bridge. > >>=20 > >> indeed. technically it is little problem changing (already=20 > works with DHCPv6). but, this is largely politically=20 > motivated. design IPv6 so that end-users get at least a /64=20 > and aren't forced to do NAT. > >=20 > > One person's "political motivations" are another person's=20 > "making the net work well" and another person's "business need". >=20 > indeed. >=20 > in any case I don't think the fact that 6to4 guarantees a /48=20 > (but with patchy connectivity ;-)), justifies that mechanism=20 > with all its shortcomings over IPv6 access (6rd or native)=20 > which may give the user a /56. or whatever the SP decides for=20 > its default, vanilla service. (I would much rather have=20 > multi-homing than larger than /56 in my home). >=20 > cheers, > Ole >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From Fred.L.Templin@boeing.com Mon Feb 14 08:59:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AABD93A6D4C for ; Mon, 14 Feb 2011 08:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wr4Xwlia+O01 for ; Mon, 14 Feb 2011 08:59:05 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id CBB0E3A6A57 for ; Mon, 14 Feb 2011 08:59:05 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1EGxQEo020301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Feb 2011 08:59:26 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1EGxQjR010598; Mon, 14 Feb 2011 08:59:26 -0800 (PST) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1EGxQir010595 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 14 Feb 2011 08:59:26 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Mon, 14 Feb 2011 08:59:25 -0800 From: "Templin, Fred L" To: George Bonser , Mikael Abrahamsson Date: Mon, 14 Feb 2011 08:59:25 -0800 Thread-Topic: [v6ops] RFC 2464 - MTU >1500 Thread-Index: AcvKXYxSa16EQfDYStWlBdLFHzFwQgAGYvCQAHwy5HA= Message-ID: References: <20110203224351.GA27225@srv03.cluenet.de><201102041342.p14DgnOV017566@cichlid .raleigh.ibm.com><20110207211826.GB13323@srv03.cluenet.de><4ABF4068-018A-4D 24-93A7-B1069AC99333@fnal.gov><20110208074710.GB18776@srv03.cluenet.de><201 102110134.p1B1YEW6009144@cichlid.raleigh.ibm.com><4D54A15D.4050700@brightok .net><5A6D953473350C4B9995546AFE9939EE0BC13A23@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AF E9939EE0BC13A6A@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13A72@RWC-EX1.corp.seven.com> In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13A72@RWC-EX1.corp.seven.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 2464 - MTU >1500 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 16:59:06 -0000 Hi George, Yes, RFC4821 is a way end systems can protect against PMTUD brokenness. However, it does not excuse routers from returning the required ICMP PTBs, and it requires that links be consistent about the size of packets they will accommodate - both of which can present challenges to in-the-network tunnels. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of George Bonser > Sent: Friday, February 11, 2011 9:46 PM > To: Mikael Abrahamsson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] RFC 2464 - MTU >1500 >=20 > http://www.ietf.org/rfc/rfc4821.txt >=20 > On by default with Windows and Solaris. Need to set > net.ipv4.tcp_mtu_probing=3D1 or 2 for linux depending on the=20 > behavior you > want. >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > > Sent: Friday, February 11, 2011 6:36 PM > > To: George Bonser > > Cc: v6ops@ietf.org > > Subject: RE: [v6ops] RFC 2464 - MTU >1500 > >=20 > > On Fri, 11 Feb 2011, George Bonser wrote: > >=20 > > > Yes, and as modern PMTUD doesn't require ICMP, it works=20 > much better > > than > > > the old way. > >=20 > > Care to elaborate on that? What "modern PMTUD" are you referring to > > that > > doesn't require any ICMP involvement? > >=20 > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From moore@network-heretics.com Mon Feb 14 09:35:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1793A6A6D for ; Mon, 14 Feb 2011 09:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.484 X-Spam-Level: X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCDbJZ6h3RTM for ; Mon, 14 Feb 2011 09:35:42 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id 4420E3A69EB for ; Mon, 14 Feb 2011 09:35:42 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 955B720993; Mon, 14 Feb 2011 12:36:05 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 14 Feb 2011 12:36:05 -0500 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=DNb/yVbeIW2V0UqlJUawH63b9lE=; b=S54U9YC0X1lNjVunlk2Q/sjRytRDRSN3eqse5X+hNibAIX7JrzQJV9pHNW1L8GyZJc1h9e3Ch2NiXVvjGDLbLgXl0PbAb85Zga5xGXPr3GBWyh8V2Zv9ebWErfiU9nsKq161OgZ4npxCl9tUbXEt041lsMueoDzK+VNTbM/m1hg= X-Sasl-enc: Cz6FHW9cDfZOun3vcPPVvNRe/or9lNsmNAwqpxr1Iu5q 1297704965 Received: from 173-6-180-61.pools.spcsdns.net (unknown [173.6.180.61]) by mail.messagingengine.com (Postfix) with ESMTPA id 501FB44196B; Mon, 14 Feb 2011 12:36:04 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110214163236.GA9513@srv03.cluenet.de> Date: Mon, 14 Feb 2011 12:36:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5EDCCBB0-A4C6-449C-B7F5-07B2302C24A8@network-heretics.com> References: <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> <20110214163236.GA9513@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 17:35:43 -0000 On Feb 14, 2011, at 11:32 AM, Daniel Roesen wrote: > On Mon, Feb 14, 2011 at 10:13:39AM -0500, Keith Moore wrote: >> Even a /64 would probably be good enough, assuming that the market >> would produce clever routers that could handle hosts on each of >> multiple links within a single /64 and implement a ND proxy to let >> the hosts talk to each other. >=20 > That's not clever, that's an ugly hack we certainly want to avoid. This is one case where I don't understand how such mechanisms would = adversely impact anyone, as long as it weren't done on too large a scale = at any particular site. Keith From dr@cluenet.de Mon Feb 14 10:50:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8442B3A6D55 for ; Mon, 14 Feb 2011 10:50:10 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3suvrMX5AMI2 for ; Mon, 14 Feb 2011 10:50:09 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 22AAD3A6A15 for ; Mon, 14 Feb 2011 10:50:07 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 13D98108092; Mon, 14 Feb 2011 19:50:30 +0100 (CET) Date: Mon, 14 Feb 2011 19:50:30 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110214185030.GB17915@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> <20110214163236.GA9513@srv03.cluenet.de> <5EDCCBB0-A4C6-449C-B7F5-07B2302C24A8@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5EDCCBB0-A4C6-449C-B7F5-07B2302C24A8@network-heretics.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 18:50:10 -0000 On Mon, Feb 14, 2011 at 12:36:02PM -0500, Keith Moore wrote: > This is one case where I don't understand how such mechanisms would > adversely impact anyone, Try to explain the average customer support agent how to diagnose and troubleshoot those kind of setups. ARP is hard. IPv6 ND is much harder. Proxy-ND: good luck. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From moore@network-heretics.com Mon Feb 14 10:53:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 545C43A6A15 for ; Mon, 14 Feb 2011 10:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ef3Ecks2IL6a for ; Mon, 14 Feb 2011 10:52:56 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id C10163A6D55 for ; Mon, 14 Feb 2011 10:52:56 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 40F3D20521; Mon, 14 Feb 2011 13:53:20 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 14 Feb 2011 13:53:20 -0500 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=RIKkUmwwZInRemSiBPeLGeoN9jQ=; b=f8c+E2D8q4JmXxcq2G85SicUvVua4zVbThjqIFXK9OIuxkSNyCln4urConZxcNJO+a0QWTjSuSz0qi+G5FGhaivBpXHctzmKQwf7b0tkv970YpNR5RUIOGK+edMMbZFZNBN16TTF8txPMNGAzn4csoeTM/IO6s/BCZXKQXyKuos= X-Sasl-enc: 8m+NBPr7fYoS4/P2ycbuAtCFgLUzzrwx7cz4nru3eVQt 1297709599 Received: from 173-6-180-61.pools.spcsdns.net (unknown [173.6.180.61]) by mail.messagingengine.com (Postfix) with ESMTPA id BD12F4432CD; Mon, 14 Feb 2011 13:53:18 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-84--572666152 From: Keith Moore In-Reply-To: <20110214185030.GB17915@srv03.cluenet.de> Date: Mon, 14 Feb 2011 13:53:17 -0500 Message-Id: <51007461-7DD8-4550-B287-5678E8D41FDB@network-heretics.com> References: <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> <20110214163236.GA9513@srv03.cluenet.de> <5EDCCBB0-A4C6-449C-B7F5-07B2302C24A8@network-heretics.com> <20110214185030.GB17915@srv03.cluenet.de> To: Daniel Roesen X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 18:53:00 -0000 --Apple-Mail-84--572666152 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 14, 2011, at 1:50 PM, Daniel Roesen wrote: > On Mon, Feb 14, 2011 at 12:36:02PM -0500, Keith Moore wrote: >> This is one case where I don't understand how such mechanisms would >> adversely impact anyone, >=20 > Try to explain the average customer support agent how to diagnose and > troubleshoot those kind of setups. >=20 > ARP is hard. IPv6 ND is much harder. Proxy-ND: good luck. I'm assuming that there would be products explicitly designed to support = that, whether by bridging or proxy ND or whatever. Certainly agree that = it's difficult to set up those things with ordinary routers. Keith --Apple-Mail-84--572666152 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Mon, Feb 14, 2011 at 12:36:02PM -0500, Keith Moore wrote:
This is one case where I don't understand how such = mechanisms would
adversely = impact anyone,

Try to explain the average customer = support agent how to diagnose and
troubleshoot those kind of = setups.

ARP is hard. IPv6 ND is much harder. Proxy-ND: good = luck.

I'm = assuming that there would be products explicitly designed to support = that, whether by bridging or proxy ND or whatever.  Certainly agree = that it's difficult to set up those things with ordinary = routers.

Keith

= --Apple-Mail-84--572666152-- From brian.e.carpenter@gmail.com Mon Feb 14 12:42:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85B803A6D46 for ; Mon, 14 Feb 2011 12:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAdSwTzwUiJd for ; Mon, 14 Feb 2011 12:42:18 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 809DD3A6C51 for ; Mon, 14 Feb 2011 12:42:18 -0800 (PST) Received: by fxm9 with SMTP id 9so6153600fxm.31 for ; Mon, 14 Feb 2011 12:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=06Psp3yOS9WWBtNboaELUv0p09inlaf06OTxHPXgZlo=; b=UMcddY7oZn5gbZgILdZxtgp3OkEFJJT3jgOUGIfVGuvYKAI77nfoENeEW6fRCdvRn0 1DOV9RpsEdnH9YT4Zmu1s3vMS6wPw6PxiEnzp7ybh+PxIAClA4uD4CXGKs/yfHFJgVMU MJt+hXArkUqxK7rQHTVqQP8aA4c100XpQX85I= 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=ESS+8WbZIXiIaHeb7+CRBqqzLHjBSE2rXxEEFqWm6DPqM66SvgTayS1ZPxNxYtSucZ CYNNMTa6ioeItbZc65WWAN9K2SOurWUQn31CRyu3t4gkNUs8248MMclxT/53aa6MFuIO 4iF1ADu4okk3w13P2DVHtSpjDMGCZjV3CAUpg= Received: by 10.223.103.4 with SMTP id i4mr5124441fao.123.1297716161585; Mon, 14 Feb 2011 12:42:41 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id f24sm1306002fak.0.2011.02.14.12.42.36 (version=SSLv3 cipher=OTHER); Mon, 14 Feb 2011 12:42:39 -0800 (PST) Message-ID: <4D5993B9.9020401@gmail.com> Date: Tue, 15 Feb 2011 09:42:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" References: <20110207151430.44A393A6DD8@core3.amsl.com> <20110207182807.GY44800@Space.Net> <4D50626A.8020801@gmail.com><4912B835-27DB-4A6C-BFAB-51069AAC3D5B@network-heretics.com> <4269EA985EACD24987D82DAE2FEC62E50316DDF3@XMB-AMS-101.cisco.com> In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E50316DDF3@XMB-AMS-101.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Keith Moore , IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 20:42:19 -0000 On 2011-02-15 00:40, Gunter Van de Velde (gvandeve) wrote: >> it is difficult to see the motivation for anyone to run a relay router > in the first place. > > To provide better service to their customers? Nah, no provider would > want to do that... > > GV> :-) ... oversimplification here. There are providing 'better' > service to people 'NOT' being their customer. Actually that's not right. Most operators will gain from making 6to4 work better, even if they have no direct subscribers using it. See draft-carpenter-v6ops-6to4-teredo-advisory for details. And this remains true as long as some subscribers are using it, regardless of whether the IETF deprecates RFC 3068. Brian From remi.despres@free.fr Tue Feb 15 08:52:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54DAA3A6CD1 for ; Tue, 15 Feb 2011 08:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.341 X-Spam-Level: X-Spam-Status: No, score=0.341 tagged_above=-999 required=5 tests=[AWL=-0.910, BAYES_50=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsYfZRj7aTvm for ; Tue, 15 Feb 2011 08:52:23 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by core3.amsl.com (Postfix) with ESMTP id 5A7003A6C6E for ; Tue, 15 Feb 2011 08:52:23 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2422.sfr.fr (SMTP Server) with ESMTP id 0C1A57000085; Tue, 15 Feb 2011 17:52:49 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2422.sfr.fr (SMTP Server) with ESMTP id 8EED87000090; Tue, 15 Feb 2011 17:52:48 +0100 (CET) X-SFR-UUID: 20110215165248585.8EED87000090@msfrf2422.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 15 Feb 2011 17:52:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <75EBF059-3EE2-44B3-A356-6BC777C211A6@free.fr> References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no><61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com><20110207175624.GA929@srv03.cluenet.de><403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 16:52:24 -0000 Le 14 f=E9vr. 2011 =E0 15:11, Keith Moore a =E9crit : > On Feb 14, 2011, at 7:21 AM, Gunter Van de Velde (gvandeve) wrote: >=20 >> Keith, >>=20 >> <>start snip<> >> My problem with 6rd is that it's not something than an individual = user >> who needs IPv6 can deploy independently of support from his ISP. =20 >> <>end snip<> >>=20 >> Actually users could use that technology ...for example, if the 6rd = ISP >> provider receives a /24 IPv6 prefix from his registry... then=20 >> the IPv4 address of the end-user can be added (24 + 32 =3D 56) then = the >> end-user still has 8 bits available for subnetting. >=20 > You're missing the point I was trying to make, which is that, unlike = 6to4, users can't make use of 6rd without the ISP having explicit = support for it. >=20 > I was aware that an ISP could give the user a /56 using 6rd. Not as = good as a /48, of course, but way better than a /64. And a /64 is way better than no ISP-provided IPv6 prefix. As a user, I am glad to know that I now have in my home office a prefix = shorter than the /64 I initially had, but this hasn't changed in = anything my user experience. Regards, RD >=20 > Keith >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From remi.despres@free.fr Tue Feb 15 09:09:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9643A6BCD for ; Tue, 15 Feb 2011 09:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.376 X-Spam-Level: X-Spam-Status: No, score=0.376 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_50=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Nh7z-nc6-7g for ; Tue, 15 Feb 2011 09:09:16 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by core3.amsl.com (Postfix) with ESMTP id 70BD03A6C64 for ; Tue, 15 Feb 2011 09:09:16 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 154D070000A2; Tue, 15 Feb 2011 18:09:42 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 5828070000A4; Tue, 15 Feb 2011 18:09:41 +0100 (CET) X-SFR-UUID: 20110215170941361.5828070000A4@msfrf2414.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 15 Feb 2011 18:09:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371579432.25658.1297097008610.JavaMail.root@claudius.linpro.no><61983A9F-7871-4DB8-9BB8-C4CF6691850D@network-heretics.com><20110207175624.GA929@srv03.cluenet.de><403A8B8B-169C-48B8-BD2F-81B2C61176D9@cisco.com> <4269EA985EACD24987D82DAE2FEC62E50316DE20@XMB-AMS-101.cisco.com> To: Keith Moore X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: New Version Notificationfordraft-troan-v6ops-6to4-to-historic-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 17:09:17 -0000 >=20 >=20 > p.s. Personally I think that allocating 64 bits to an interface = identifier, and wiring that into the v6 architecture, were very = shortsighted. =20 > I think there will be a number of important cases where sites will = need to subnet past /64. =20 I agree that permitting link prefixes longer than /64 opens a number of = useful opportunities, in particular to avoid the use of NATs in IPv6, = and thus preserve e2e address transparency. There are various ways to permit such long prefixes without sacrificing = backward compatibility, but this is another story. IMHO, priority is to accelerate a generalized deployment of native IPv6 = addresses. Regards, RD > I'm also one of those people who wishes that the IPng people had tried = harder to find a way to make variable length addresses work. But those = are water under the bridge. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From SHogg@GTRI.com Wed Feb 16 14:02:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF1B83A6DB2 for ; Wed, 16 Feb 2011 14:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaUmWtDiWSe2 for ; Wed, 16 Feb 2011 14:02:10 -0800 (PST) Received: from SRVDE-CHT02.GTRInt.COM (srvde-cht02.gtrint.com [63.255.26.22]) by core3.amsl.com (Postfix) with ESMTP id D342D3A6AFD for ; Wed, 16 Feb 2011 14:02:10 -0800 (PST) Received: from GTRI-MBX.GTRInt.COM ([fe80:0000:0000:0000:1147:552e:28.252.226.217]) by SRVDE-CHT02.GTRInt.COM ([10.38.40.161]) with mapi; Wed, 16 Feb 2011 15:02:59 -0700 From: Scott Hogg To: "v6ops@ietf.org" Date: Wed, 16 Feb 2011 15:02:32 -0700 Thread-Topic: 2011 Rocky Mountain IPv6 Summit Thread-Index: AcvOJTW1AMktlcmRS1OFA8OYhKK3HQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AsKi DIbk EwnI Fpph Fx6y GDWm Ga9R HZ1e Hm3Y HtR7 Ipiy JJL2 JR5Z JUhe Ko10 MZDk; 1; dgA2AG8AcABzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {E49129AC-9614-4835-8843-68A68650A6BF}; cwBoAG8AZwBnAEAAZwB0AHIAaQAuAGMAbwBtAA==; Wed, 16 Feb 2011 22:02:32 GMT; MgAwADEAMQAgAFIAbwBjAGsAeQAgAE0AbwB1AG4AdABhAGkAbgAgAEkAUAB2ADYAIABTAHUAbQBtAGkAdAA= x-cr-puzzleid: {E49129AC-9614-4835-8843-68A68650A6BF} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B57FF3E802A0FC46811AC1C745350E510379DC1279GTRIMBXGTRInt_" MIME-Version: 1.0 Subject: [v6ops] 2011 Rocky Mountain IPv6 Summit X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 22:02:12 -0000 --_000_B57FF3E802A0FC46811AC1C745350E510379DC1279GTRIMBXGTRInt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We invite you to attend the 2011 Rocky Mountain IPv6 Summit at the Grand Hy= att Denver, Colorado, April 25, 26-27, 2011! The Rocky Mountain IPv6 Summit is the largest annual IPv6 event in North Am= erica. This event is designed to educate and update you on the current sta= te of IPv6 adoption. Attendees will learn about what other organizations are doing to prepare fo= r the migration to IPv6 and learn from those who are already utilizing the = benefits of IPv6. You will collaborate with colleagues who are actively wo= rking on IPv6 research and implementation and learn about IPv6 technology f= rom industry experts. New this year is an optional pre-conference tutorial on the first day. The= pre-conference tutorial includes a full day of training, materials and mea= ls. The 2-day conference begins on April 26 and includes a day of Enterprise an= d Service Provider tutorials. Day 2 of the conference covers multi-track s= ubjects with expert speakers. More information is available at: http://www.rmv6tf.org Here is the registration link http://events.constantcontact.com/register/event?llr=3Dnaox5fdab&oeidk=3Da0= 7e3a7v8aid91b1edd Sincerely, Scott Hogg Chair - Rocky Mountain IPv6 Task Force 303-949-4865 scott@rmv6tf.org --_000_B57FF3E802A0FC46811AC1C745350E510379DC1279GTRIMBXGTRInt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We invite you to= attend the 2011 Rocky Mountain IPv6 Summit at the Grand Hyatt Denver, Colo= rado, April 25, 26-27, 2011! 

 

The Rocky Mountain IPv6 Summit is the= largest annual IPv6 event in North America.  This event is designed t= o educate and update you on the current state of IPv6 adoption.  =

 

At= tendees will learn about what other organizations are doing to prepare for = the migration to IPv6 and learn from those who are already utilizing the be= nefits of IPv6.  You will collaborate with colleagues who are actively= working on IPv6 research and implementation and learn about IPv6 technolog= y from industry experts.

 

New this year is an optional pre-conference tuto= rial on the first day.  The pre-conference tutorial includes a full da= y of training, materials and meals. 

The 2-day conference begins on April 26 and includes a day of Enterprise= and Service Provider tutorials.  Day 2 of the conference covers multi= -track subjects with expert speakers.

<= o:p> 

More information is available at:<= o:p>

http://www.rmv6tf.org

 

Here is the regi= stration link

http://events.constantcont= act.com/register/event?llr=3Dnaox5fdab&oeidk=3Da07e3a7v8aid91b1edd=

 

Si= ncerely,

 

Scott Hogg

Chair - Rocky Mo= untain IPv6 Task Force

303-949-4865=

scott@rmv6tf.org

= = --_000_B57FF3E802A0FC46811AC1C745350E510379DC1279GTRIMBXGTRInt_-- From zhangdong_rh@huaweisymantec.com Wed Feb 16 17:54:14 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA783A6EEC; Wed, 16 Feb 2011 17:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.709 X-Spam-Level: *** X-Spam-Status: No, score=3.709 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3eTEqYHH5K4; Wed, 16 Feb 2011 17:54:14 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 959AF3A6BA0; Wed, 16 Feb 2011 17:54:13 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_4znOfmVJn62G/Iu036WXCw)" Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LGQ0071HNYWBH10@hstga02-in.huaweisymantec.com>; Thu, 17 Feb 2011 09:54:32 +0800 (CST) Received: from Z90001956Z ([10.27.136.91]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LGQ00KV9NYTAZ20@hstml02-in.huaweisymantec.com>; Thu, 17 Feb 2011 09:54:32 +0800 (CST) Date: Thu, 17 Feb 2011 09:54:30 +0800 From: Dong Zhang To: v6ops References: <20110217011001.69BDE3A6D34@core3.amsl.com> Message-id: <201102170954297669884@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Cc: "behave@ietf.org" Subject: [v6ops] Fw: New Version Notification for draft-zhang-v6ops-cgn-source-trace-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 01:54:15 -0000 This is a multi-part message in MIME format. --Boundary_(ID_4znOfmVJn62G/Iu036WXCw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgZm9sa3MsDQoNCldlIGhhdmUgcHJvcG9zZWQgYSBuZXcgZHJhZnQgYWJvdXQgdGhlIHNvdXJj ZSBhZGRyZXNzIHRyYWNpbmcgaXNzdWUuIA0KQXMgdGhlIENHTiBpcyBkZXBsb3llZCwgdGhlIElQ djQgYWRkcmVzcyB3aWxsIGJlIHNoYXJlZCBieSBtb3JlIHRoYW4gb25lIHVzZXJzLiBUaGUgZHJh ZnQgdGFsa3MgYWJvdXQgdGhlIHJlcXVpcmVtZW50cyBhbmQgdGhlIHNvbHV0aW9uIG1vZGVscyBm b3Igc291cmNlIGFkZHJlc3MgdHJhY2luZy4NCg0KV2VsY29tZSBjb21tZW50Lg0KVGhhbmtzLg0K DQoNCjIwMTEtMDItMTcNCg0KDQoNCkRvbmcgWmhhbmcNCg0KDQoNCg0Kt6K8/sjLo7ogSUVURiBJ LUQgU3VibWlzc2lvbiBUb29sDQq3osvNyrG85KO6IDIwMTEtMDItMTcgMDk6MTA6MzMNCsrVvP7I y6O6IHpoYW5nZG9uZ19yaEBodWF3ZWlzeW1hbnRlYy5jb20NCrOty82juiANCtb3zOKjuiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXpoYW5nLXY2b3BzLWNnbi1zb3VyY2UtdHJh Y2UtMDANCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtemhhbmctdjZvcHMtY2duLXNv dXJjZS10cmFjZS0wMC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEb25n IFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICBk cmFmdC16aGFuZy12Nm9wcy1jZ24tc291cmNlLXRyYWNlDQpSZXZpc2lvbjogIDAwDQpUaXRsZTog IFNvbHV0aW9uIE1vZGVsIG9mIFNvdXJjZSBBZGRyZXNzIFRyYWNpbmcgZm9yIENhcnJpZXIgR3Jh ZGUgTkFUIChDR04pDQpDcmVhdGlvbl9kYXRlOiAgMjAxMS0wMi0xNg0KV0cgSUQ6ICBJbmRlcGVu ZGVudCBTdWJtaXNzaW9uDQpOdW1iZXJfb2ZfcGFnZXM6IDgNCg0KQWJzdHJhY3Q6DQpTaW5jZSBO QVQgZnVuY3Rpb24gb24gQ0dOIGJveCB3aWxsIG1ha2UgdGhlIElQdjQgYWRkcmVzcyByZS11c2Vk IGJ5DQptb3JlIHRoYW4gb25lIHVzZXIsIHRoZSBwYWNrZXRzIHNlbnQgb3V0c2lkZSBDR04gYXJl IG5vdCBhYmxlIHRvIGJlDQppZGVudGlmaWQgd2hlcmUgdGhleSBhcmUgZnJvbSBvciB3aGljaCB1 c2VyIHRoZXkgYmVsb25nIHRvIGFjY29yZGluZw0KdG8gdGhlIHNvdXJjZSBhZGRyZXNzIHdpdGhp biB0aGUgcGFja2V0cy4gIEhvd2V2ZXIsIHVuZGVyIHNvbWUNCmNlcnRhaW4gY2lyY3Vtc3RhbmNl cywga25vd2luZyB0aGUgb3JpZ2luYWwgc291cmNlIElQIGFkZHJlc3MgYW5kIHRoZQ0KaWRlbnRp dHkgb2YgdGhlIHVzZXIgd2hvIHNlbmRzIHRoZSBwYWNrZXQgb3V0IGlzIG5lY2Vzc2FyeS4gIFRo aXMNCmRvY3VtZW50IHN0YXRlcyB0aGUgcmVxdWlyZW1lbnQgb2Ygc291cmNlIGFkZHJlc3MgdHJh Y2luZyBicmllZmx5LA0KYW5kIGRpc2N1c3NlcyB0aGUgcG9zc2libGUgc29sdXRpb24gbW9kZWxz IGZvciB0aGlzIGlzc3VlLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0Lg0K --Boundary_(ID_4znOfmVJn62G/Iu036WXCw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC43NjAwLjE2NzAwIj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElH TjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg Um9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5kb3d0ZXh0 OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJGT05ULUZBTUlMWTogdmVyZGFuYTsgRk9OVC1TSVpFOiAxMHB0Ij4NCjxESVY+PEZP TlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPkhpIGZvbGtzLDwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGNvbG9yPSMwMDAwODA+V2UgaGF2ZSBwcm9wb3NlZCBhIG5ldyBkcmFmdCBhYm91dCB0aGUg c291cmNlIGFkZHJlc3MgDQp0cmFjaW5nIGlzc3VlLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGNvbG9yPSMwMDAwODA+QXMgdGhlIENHTiBpcyBkZXBsb3llZCwgdGhlIElQdjQgYWRkcmVzcyB3 aWxsIGJlIHNoYXJlZCANCmJ5IG1vcmUgdGhhbiBvbmUgdXNlcnMuIFRoZSBkcmFmdCB0YWxrcyBh Ym91dCB0aGUgcmVxdWlyZW1lbnRzIGFuZCB0aGUgc29sdXRpb24gDQptb2RlbHMgZm9yIHNvdXJj ZSBhZGRyZXNzIHRyYWNpbmcuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgw PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD5XZWxjb21lIGNv bW1lbnQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPlRoYW5rcy48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+MjAx MS0wMi0xNzwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWIGFsaWduPWxlZnQ+DQo8RElWIGFsaWdu PWxlZnQ+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxIUiBzdHlsZT0iV0lEVEg6IDEyMnB4 OyBIRUlHSFQ6IDJweCIgU0laRT0yPg0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0j YzBjMGMwPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNQQU4+DQo8RElWPg0KPERJVj48Rk9O VCBzaXplPTIgZmFjZT1WZXJkYW5hPkRvbmcgDQpaaGFuZzxCUj48L0ZPTlQ+PC9ESVY+PC9ESVY+ PC9TUEFOPjwvRk9OVD48L0RJVj48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFu YT4NCjxIUj4NCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNp emU9Mj48U1RST05HPreivP7Iy6O6PC9TVFJPTkc+IElFVEYgSS1EIFN1Ym1pc3Npb24gDQpUb29s PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9 Mj48U1RST05HPreiy83Ksbzko7o8L1NUUk9ORz4gDQoyMDExLTAyLTE3Jm5ic3A7MDk6MTA6MzM8 L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0y PjxTVFJPTkc+ytW8/sjLo7o8L1NUUk9ORz4gDQp6aGFuZ2RvbmdfcmhAaHVhd2Vpc3ltYW50ZWMu Y29tPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNp emU9Mj48U1RST05HPrOty82jujwvU1RST05HPiA8L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0yPjxTVFJPTkc+1vfM4qO6PC9TVFJPTkc+IE5l dyBWZXJzaW9uIA0KTm90aWZpY2F0aW9uIGZvciBkcmFmdC16aGFuZy12Nm9wcy1jZ24tc291cmNl LXRyYWNlLTAwPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVy ZGFuYT48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5BJm5ic3A7bmV3Jm5ic3A7dmVyc2lvbiZuYnNwO29m Jm5ic3A7SS1ELCZuYnNwO2RyYWZ0LXpoYW5nLXY2b3BzLWNnbi1zb3VyY2UtdHJhY2UtMDAudHh0 Jm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3N1Y2Nlc3NmdWxseSZuYnNwO3N1Ym1pdHRlZCZuYnNw O2J5Jm5ic3A7RG9uZyZuYnNwO1poYW5nJm5ic3A7YW5kJm5ic3A7cG9zdGVkJm5ic3A7dG8mbmJz cDt0aGUmbmJzcDtJRVRGJm5ic3A7cmVwb3NpdG9yeS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPkZpbGVuYW1lOiAmbmJzcDtkcmFmdC16aGFuZy12Nm9wcy1jZ24tc291cmNlLXRyYWNl PC9ESVY+DQo8RElWPlJldmlzaW9uOiAmbmJzcDswMDwvRElWPg0KPERJVj5UaXRsZTogDQombmJz cDtTb2x1dGlvbiZuYnNwO01vZGVsJm5ic3A7b2YmbmJzcDtTb3VyY2UmbmJzcDtBZGRyZXNzJm5i c3A7VHJhY2luZyZuYnNwO2ZvciZuYnNwO0NhcnJpZXImbmJzcDtHcmFkZSZuYnNwO05BVCZuYnNw OyhDR04pPC9ESVY+DQo8RElWPkNyZWF0aW9uX2RhdGU6ICZuYnNwOzIwMTEtMDItMTY8L0RJVj4N CjxESVY+V0cmbmJzcDtJRDogJm5ic3A7SW5kZXBlbmRlbnQmbmJzcDtTdWJtaXNzaW9uPC9ESVY+ DQo8RElWPk51bWJlcl9vZl9wYWdlczombmJzcDs4PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj5BYnN0cmFjdDo8L0RJVj4NCjxESVY+U2luY2UmbmJzcDtOQVQmbmJzcDtmdW5jdGlvbiZu YnNwO29uJm5ic3A7Q0dOJm5ic3A7Ym94Jm5ic3A7d2lsbCZuYnNwO21ha2UmbmJzcDt0aGUmbmJz cDtJUHY0Jm5ic3A7YWRkcmVzcyZuYnNwO3JlLXVzZWQmbmJzcDtieTwvRElWPg0KPERJVj5tb3Jl Jm5ic3A7dGhhbiZuYnNwO29uZSZuYnNwO3VzZXIsJm5ic3A7dGhlJm5ic3A7cGFja2V0cyZuYnNw O3NlbnQmbmJzcDtvdXRzaWRlJm5ic3A7Q0dOJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7YWJsZSZu YnNwO3RvJm5ic3A7YmU8L0RJVj4NCjxESVY+aWRlbnRpZmlkJm5ic3A7d2hlcmUmbmJzcDt0aGV5 Jm5ic3A7YXJlJm5ic3A7ZnJvbSZuYnNwO29yJm5ic3A7d2hpY2gmbmJzcDt1c2VyJm5ic3A7dGhl eSZuYnNwO2JlbG9uZyZuYnNwO3RvJm5ic3A7YWNjb3JkaW5nPC9ESVY+DQo8RElWPnRvJm5ic3A7 dGhlJm5ic3A7c291cmNlJm5ic3A7YWRkcmVzcyZuYnNwO3dpdGhpbiZuYnNwO3RoZSZuYnNwO3Bh Y2tldHMuJm5ic3A7Jm5ic3A7SG93ZXZlciwmbmJzcDt1bmRlciZuYnNwO3NvbWU8L0RJVj4NCjxE SVY+Y2VydGFpbiZuYnNwO2NpcmN1bXN0YW5jZXMsJm5ic3A7a25vd2luZyZuYnNwO3RoZSZuYnNw O29yaWdpbmFsJm5ic3A7c291cmNlJm5ic3A7SVAmbmJzcDthZGRyZXNzJm5ic3A7YW5kJm5ic3A7 dGhlPC9ESVY+DQo8RElWPmlkZW50aXR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDt1c2VyJm5ic3A7 d2hvJm5ic3A7c2VuZHMmbmJzcDt0aGUmbmJzcDtwYWNrZXQmbmJzcDtvdXQmbmJzcDtpcyZuYnNw O25lY2Vzc2FyeS4mbmJzcDsmbmJzcDtUaGlzPC9ESVY+DQo8RElWPmRvY3VtZW50Jm5ic3A7c3Rh dGVzJm5ic3A7dGhlJm5ic3A7cmVxdWlyZW1lbnQmbmJzcDtvZiZuYnNwO3NvdXJjZSZuYnNwO2Fk ZHJlc3MmbmJzcDt0cmFjaW5nJm5ic3A7YnJpZWZseSw8L0RJVj4NCjxESVY+YW5kJm5ic3A7ZGlz Y3Vzc2VzJm5ic3A7dGhlJm5ic3A7cG9zc2libGUmbmJzcDtzb2x1dGlvbiZuYnNwO21vZGVscyZu YnNwO2ZvciZuYnNwO3RoaXMmbmJzcDtpc3N1ZS48L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+VGhlJm5ic3A7SUVURiZuYnNwO1NlY3JldGFyaWF0LjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvRk9O VD48L0RJVj48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_4znOfmVJn62G/Iu036WXCw)-- From joelja@bogus.com Thu Feb 17 22:47:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29FDF3A6D71 for ; Thu, 17 Feb 2011 22:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Og-4yv46szbI for ; Thu, 17 Feb 2011 22:47:20 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 428333A6D6D for ; Thu, 17 Feb 2011 22:47:17 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p1I6lgm7020199 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 18 Feb 2011 06:47:45 GMT (envelope-from joelja@bogus.com) Message-ID: <4D5E160D.2010409@bogus.com> Date: Thu, 17 Feb 2011 22:47:41 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: draft-zhang-v6ops-cgn-source-trace@tools.ietf.org, IPv6 Ops WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Fri, 18 Feb 2011 06:47:47 +0000 (UTC) Cc: David Harrington Subject: [v6ops] thoughts on the draft... http://tools.ietf.org/html/draft-zhang-v6ops-cgn-source-trace-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 06:47:22 -0000 The question "whose using this source/dest/sport/dport tupple is right now" really means, when I originated the question. the question is always in the past tense (who was using it at time-t, even in the case of an onging connection) we answer this question in the context of webservers all the time. I think this draft could probably be turned into a reasonable statement of the problem, but I don't think there's really a major difference between the two cases. if you were looking for a location for this work I would consider transport and specifically behave as potentially appropriate location for such. I would also encourage the authors to ponder rfc 2804 when considering how and under what circumstances the ietf would undertake to standardize the functionality the problem statement requires... Transport AD copied to close loop. From zhangdong_rh@huaweisymantec.com Fri Feb 18 00:10:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6DE3A6DF8; Fri, 18 Feb 2011 00:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.709 X-Spam-Level: *** X-Spam-Status: No, score=3.709 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZbOlXQ8Z7zt; Fri, 18 Feb 2011 00:10:35 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id B0EFF3A6CE6; Fri, 18 Feb 2011 00:10:34 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_5Pwco46EAL1YTTGNiuvogQ)" Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LGT00445029OT70@hstga02-in.huaweisymantec.com>; Fri, 18 Feb 2011 16:10:57 +0800 (CST) Received: from Z90001956Z ([10.27.136.91]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LGT000G7025GN00@hstml02-in.huaweisymantec.com>; Fri, 18 Feb 2011 16:10:57 +0800 (CST) Date: Fri, 18 Feb 2011 16:10:53 +0800 From: Dong Zhang To: Joel Jaeggli , draft-zhang-v6ops-cgn-source-tra , IPv6 Ops WG , behave References: <4D5E160D.2010409@bogus.com> Message-id: <201102181610534957820@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Cc: David Harrington Subject: Re: [v6ops] thoughts on the draft...http://tools.ietf.org/html/draft-zhang-v6ops-cgn-source-trace-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 08:10:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_5Pwco46EAL1YTTGNiuvogQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgSm9lbCwNCg0KVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLg0KUGxlYXNlIHNlZSBpbmxpbmVz Lg0KDQoNCg0KDQq3orz+yMujuiBKb2VsIEphZWdnbGkgDQq3osvNyrG85KO6IDIwMTEtMDItMTgg IDE0OjQ4OjA2IA0KytW8/sjLo7ogZHJhZnQtemhhbmctdjZvcHMtY2duLXNvdXJjZS10cmFjZUB0 b29scy5pZXRmLm9yZzsgSVB2NiBPcHMgV0cgDQqzrcvNo7ogRGF2aWQgSGFycmluZ3RvbiANCtb3 zOKjuiB0aG91Z2h0cyBvbiB0aGUgZHJhZnQuLi5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC16aGFuZy12Nm9wcy1jZ24tc291cmNlLXRyYWNlLTAwIA0KIA0KVGhlIHF1ZXN0aW9uICJ3 aG9zZSB1c2luZyB0aGlzIHNvdXJjZS9kZXN0L3Nwb3J0L2Rwb3J0IHR1cHBsZSBpcyByaWdodA0K bm93IiByZWFsbHkgbWVhbnMsIHdoZW4gSSBvcmlnaW5hdGVkIHRoZSBxdWVzdGlvbi4NCg0KdGhl IHF1ZXN0aW9uIGlzIGFsd2F5cyBpbiB0aGUgcGFzdCB0ZW5zZSAod2hvIHdhcyB1c2luZyBpdCBh dCB0aW1lLXQsDQpldmVuIGluIHRoZSBjYXNlIG9mIGFuIG9uZ2luZyBjb25uZWN0aW9uKQ0KDQp3 ZSBhbnN3ZXIgdGhpcyBxdWVzdGlvbiBpbiB0aGUgY29udGV4dCBvZiB3ZWJzZXJ2ZXJzIGFsbCB0 aGUgdGltZS4NCg0KSSB0aGluayB0aGlzIGRyYWZ0IGNvdWxkIHByb2JhYmx5IGJlIHR1cm5lZCBp bnRvIGEgcmVhc29uYWJsZSBzdGF0ZW1lbnQNCm9mIHRoZSBwcm9ibGVtLCBidXQgSSBkb24ndCB0 aGluayB0aGVyZSdzIHJlYWxseSBhIG1ham9yIGRpZmZlcmVuY2UNCmJldHdlZW4gdGhlIHR3byBj YXNlcy4NCg0KKioqKioqKioqKioqKioqKioqKioqKioqDQpbRG9uZ10gSWYgSSB1bmRlcnN0YW5k IHlvdXIgY29tbWVudCBjb3JyZWN0bHksIEkgdGhpbmsgdGhlcmUgaXMgYSBtaXN1bmRlcnN0YW5k aW5nLiANCg0KSSBhZ3Jlc3MgdGhhdCB3aGVuIGFueSBxdWVyeSBhY3Rpb24gaGFwcGVucywgdGhl IGluZm9ybWF0aW9uIG9mIHRoZSBxdWVyeSBzaG91bGQgDQphbHJlYWR5IGhhdmUgYmVlbiBwcm9k dWNlZC4gVGh1cywgdGhlIGFuc3dlciBpcyBhbHdheXMgaW4gcGFzdCB0aW1lLiANCkJ1dCB3aGF0 IEkgYW0gdHJ5aW5nIHRvIHNheSBpbiB0aGUgZHJhZnQgaXMgdGhhdCB3aGVuIHNvdXJjZSB0cmFj aW5nIGJlaGF2aW9yIGhhcHBlbnMsIA0KdGhlIHNlc3Npb24gdHJhbnNsYXRpb24gYmluZGluZyBp cyBzdGlsbCBhY3RpdmUgb24gdGhlIENHTiBib3guIFRoaXMgY2FzZSBpcyBjYWxsZWQNCnJlbGF0 aW1lIHRyYWNpbmcuDQpUaGUgb3RoZXIgY2FzZSBpcyBub24tcmVsYXRpbWUgdHJhY2luZy4gQmVj YXVzZSB0aGUgbG9nIHNlcnZlciBzdG9yZXMgdGhlIGhpc3RvcnkgDQppbmZvcm1hdGlvbiwgd2hl biB0aGUgdHJhY2luZyBhY3Rpb24gaGFwcGVucywgdGhlIHNlc3Npb24gYmluZGluZyBoYXMgYmVl biBkZWxldGVkIG9uDQpDR04gYm94LiAgDQoqKioqKioqKioqKioqKioqKioqKioqKioNCg0KaWYg eW91IHdlcmUgbG9va2luZyBmb3IgYSBsb2NhdGlvbiBmb3IgdGhpcyB3b3JrIEkgd291bGQgY29u c2lkZXINCnRyYW5zcG9ydCBhbmQgc3BlY2lmaWNhbGx5IGJlaGF2ZSBhcyBwb3RlbnRpYWxseSBh cHByb3ByaWF0ZSBsb2NhdGlvbg0KZm9yIHN1Y2guDQoNCioqKioqKioqKioqKioqKioqKioqKioq Kg0KW0RvbmddIEkga25vdyBzZXZlcmFsIGNhcnJpZXJzIGhhdmUgcHJvcG9zZWQgdGhlIHNvdXJj ZSBhZGRyZXNzIHRyYWNpbmcgcmVxdWlyZW1lbnQgDQpleHBsaWNpdGx5LiBUaGV5IGFzayB0aGUg Q0dOIHZlbmRvcnMgZm9yIHRyYWNpbmcgc29sdXRpb24gd2hlbiB0aGV5IGNvbnNpZGVyIGRlcGxv eWluZyANCk5BVDQ0NCwgRFMtTGl0ZSBhbmQgTkFUNjQuIEJhc2VkIG9uIHRoaXMgcmVhc29uLCBp IHRoaW5rIGEgZ3VpZGFuY2UgZG9jdW1lbnQgbWF5IGJlIA0KbmVlZGVkLiANCg0KQWN0dWFsbHks IHRoZSBwcm9ibGVtIGhhcyBiZWVuIHBvaW50ZWQgb3V0IGluIGRyYWZ0LWlldGYtdjZvcHMtdjYt aW4tbW9iaWxlLW5ldHdvcmtzLTAzLg0KDQpkcmFmdC1pZXRmLXY2b3BzLXY2LWluLW1vYmlsZS1u ZXR3b3Jrcy0wMyBzYXlzOg0KDQogICBJbiBhZGRpdGlvbiB0byB0aGUgZGV2ZWxvcG1lbnRzIGNp dGVkIGFib3ZlLCBOQVQgcGxhY2VtZW50IGlzDQogICBpbXBvcnRhbnQgZm9yIG90aGVyIHJlYXNv bnMuICBBY2Nlc3MgbmV0d29ya3MgZ2VuZXJhbGx5IG5lZWQgdG8NCiAgIHByb2R1Y2UgbmV0d29y ayBhbmQgc2VydmljZSB1c2FnZSByZWNvcmRzIGZvciBiaWxsaW5nIGFuZCBhY2NvdW50aW5nLg0K ICAgVGhpcyBpcyB0cnVlIGZvciBtb2JpbGUgbmV0d29ya3MgYXMgd2VsbCB3aGVyZSAic3Vic2Ny aWJlcg0KICAgbWFuYWdlbWVudCIgZmVhdHVyZXMgKGkuZS4sIFFvUywgUG9saWN5LCBhbmQgQmls bGluZyBhbmQgQWNjb3VudGluZykNCiAgIGNhbiBiZSBmYWlybHkgZGV0YWlsZWQuICBTaW5jZSBh IE5BVCBpbnRyb2R1Y2VzIGEgYmluZGluZyBiZXR3ZWVuIHR3bw0KICAgYWRkcmVzc2VzLCB0aGUg YmluZGluZ3MgdGhlbXNlbHZlcyBiZWNvbWUgbmVjZXNzYXJ5IGluZm9ybWF0aW9uIGZvcg0KICAg c3Vic2NyaWJlciBtYW5hZ2VtZW50LiAgRm9yIGluc3RhbmNlLCB0aGUgb2ZmZXJlZCBRb1Mgb24g cHJpdmF0ZSBJUHY0DQogICBhZGRyZXNzIGFuZCB0aGUgKHNoYXJlZCkgcHVibGljIElQdjQgYWRk cmVzcyBtYXkgbmVlZCB0byBiZQ0KICAgY29ycmVsYXRlZCBmb3IgYWNjb3VudGluZyBwdXJwb3Nl cy4gIEFzIGFub3RoZXIgZXhhbXBsZSwgdGhlDQogICBBcHBsaWNhdGlvbiBTZXJ2ZXJzIHdpdGhp biB0aGUgcHJvdmlkZXIgbmV0d29yayBtYXkgbmVlZCB0byB0cmVhdA0KICAgdHJhZmZpYyBiYXNl ZCBvbiBwb2xpY3kgcHJvdmlkZWQgYnkgdGhlIFBDUkYuICBJZiB0aGUgSVAgYWRkcmVzcyBzZWVu DQogICBieSB0aGVzZSBBcHBsaWNhdGlvbiBTZXJ2ZXJzIGlzIG5vdCB1bmlxdWUsIHRoZSBQQ1JG IG5lZWRzIHRvIGJlIGFibGUNCiAgIHRvIGluc3BlY3QgdGhlIE5BVCBiaW5kaW5nIHRvIGRpc2Ft YmlndWF0ZSBhbW9uZyB0aGUgaW5kaXZpZHVhbCBNTnMuDQogICBBbmQsIHRoZSBzdWJzY3JpYmVy IHNlc3Npb24gbWFuYWdlbWVudCBpbmZvcm1hdGlvbiBhbmQgdGhlIHNlcnZpY2UNCiAgIHVzYWdl IGluZm9ybWF0aW9uIGFsc28gbmVlZCB0byBiZSBjb3JyZWxhdGVkIGluIG9yZGVyIHRvIHByb2R1 Y2UNCiAgIGhhcm1vbml6ZWQgcmVjb3Jkcy4gIEZ1cnRoZXJtb3JlLCB0aGVyZSBtYXkgYmUgbGVn YWwgcmVxdWlyZW1lbnRzIGZvcg0KICAgc3RvcmluZyB0aGUgTkFUIGJpbmRpbmcgcmVjb3Jkcy4g IEluZGVlZCwgdGhlc2UgcHJvYmxlbXMgZGlzYXBwZWFyDQogICB3aXRoIHRoZSB0cmFuc2l0aW9u IHRvIElQdjYuICBGb3Igbm93LCBpdCBzdWZmaWNlcyB0byBzdGF0ZSB0aGF0IE5BVA0KICAgaW50 cm9kdWNlcyBzdGF0ZSB3aGljaCBuZWVkcyB0byBiZSBjb3JyZWxhdGVkIGFuZCBwb3NzaWJseSBz dG9yZWQNCiAgIHdpdGggb3RoZXIgcm91dGluZSBzdWJzY3JpYmVyIGluZm9ybWF0aW9uLg0KDQoN Ckhvd2V2ZXIsIHRoZSBhaW0gb2YgZHJhZnQtemhhbmctdjZvcHMtY2duLXNvdXJjZS10cmFjZSBp cyBpbnRyb2R1Y2luZyB0aGUgZGVwbG95bWVudCANCm1vZGVscyBvZiBzb3VyY2UgdHJhY2luZyBz b2x1dGlvbi4gDQoNClRoYW5rIHlvdS4NCg0KKioqKioqKioqKioqKioqKioqKioqKioqDQoNCkkg d291bGQgYWxzbyBlbmNvdXJhZ2UgdGhlIGF1dGhvcnMgdG8gcG9uZGVyIHJmYyAyODA0IHdoZW4g Y29uc2lkZXJpbmcNCmhvdyBhbmQgdW5kZXIgd2hhdCBjaXJjdW1zdGFuY2VzIHRoZSBpZXRmIHdv dWxkIHVuZGVydGFrZSB0byBzdGFuZGFyZGl6ZQ0KdGhlIGZ1bmN0aW9uYWxpdHkgdGhlIHByb2Js ZW0gc3RhdGVtZW50IHJlcXVpcmVzLi4uDQoNClRyYW5zcG9ydCBBRCBjb3BpZWQgdG8gY2xvc2Ug bG9vcC4NCg== --Boundary_(ID_5Pwco46EAL1YTTGNiuvogQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC43NjAwLjE2NzAwIj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElH TjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg Um9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5kb3d0ZXh0 OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJGT05ULUZBTUlMWTogdmVyZGFuYTsgRk9OVC1TSVpFOiAxMHB0Ij4NCjxESVY+PEZP TlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPkhpIEpvZWwsPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgY29sb3I9IzAwMDA4MD5UaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UuPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPlBsZWFzZSBzZWUgaW5saW5lcy48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPjxGT05UIGNvbG9y PSMwMDAwODAgc2l6ZT0yIA0KZmFjZT1WZXJkYW5hPg0KPEhSPg0KPC9GT05UPg0KPERJVj48Rk9O VCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+t6K8/sjLo7o8L1NUUk9ORz4gSm9lbCBKYWVn Z2xpIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05H Preiy83Ksbzko7o8L1NUUk9ORz4gMjAxMS0wMi0xOCZuYnNwOyAxNDo0ODowNiANCjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPsrVvP7Iy6O6PC9T VFJPTkc+IA0KZHJhZnQtemhhbmctdjZvcHMtY2duLXNvdXJjZS10cmFjZUB0b29scy5pZXRmLm9y ZzsgSVB2NiBPcHMgV0cgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJk YW5hPjxTVFJPTkc+s63LzaO6PC9TVFJPTkc+IERhdmlkIEhhcnJpbmd0b24gDQo8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7W98zio7o8L1NUUk9O Rz4gdGhvdWdodHMgb24gdGhlIA0KZHJhZnQuLi5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC16aGFuZy12Nm9wcy1jZ24tc291cmNlLXRyYWNlLTAwIA0KPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9OVD4gPC9ESVY+DQo8RElWPjxGT05UIHNp emU9MiBmYWNlPVZlcmRhbmE+DQo8RElWPlRoZSZuYnNwO3F1ZXN0aW9uJm5ic3A7Indob3NlJm5i c3A7dXNpbmcmbmJzcDt0aGlzJm5ic3A7c291cmNlL2Rlc3Qvc3BvcnQvZHBvcnQmbmJzcDt0dXBw bGUmbmJzcDtpcyZuYnNwO3JpZ2h0PC9ESVY+DQo8RElWPm5vdyImbmJzcDtyZWFsbHkmbmJzcDtt ZWFucywmbmJzcDt3aGVuJm5ic3A7SSZuYnNwO29yaWdpbmF0ZWQmbmJzcDt0aGUmbmJzcDtxdWVz dGlvbi48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPnRoZSZuYnNwO3F1ZXN0aW9uJm5i c3A7aXMmbmJzcDthbHdheXMmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO3Bhc3QmbmJzcDt0ZW5zZSZu YnNwOyh3aG8mbmJzcDt3YXMmbmJzcDt1c2luZyZuYnNwO2l0Jm5ic3A7YXQmbmJzcDt0aW1lLXQs PC9ESVY+DQo8RElWPmV2ZW4mbmJzcDtpbiZuYnNwO3RoZSZuYnNwO2Nhc2UmbmJzcDtvZiZuYnNw O2FuJm5ic3A7b25naW5nJm5ic3A7Y29ubmVjdGlvbik8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPndlJm5ic3A7YW5zd2VyJm5ic3A7dGhpcyZuYnNwO3F1ZXN0aW9uJm5ic3A7aW4mbmJz cDt0aGUmbmJzcDtjb250ZXh0Jm5ic3A7b2YmbmJzcDt3ZWJzZXJ2ZXJzJm5ic3A7YWxsJm5ic3A7 dGhlJm5ic3A7dGltZS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkmbmJzcDt0aGlu ayZuYnNwO3RoaXMmbmJzcDtkcmFmdCZuYnNwO2NvdWxkJm5ic3A7cHJvYmFibHkmbmJzcDtiZSZu YnNwO3R1cm5lZCZuYnNwO2ludG8mbmJzcDthJm5ic3A7cmVhc29uYWJsZSZuYnNwO3N0YXRlbWVu dDwvRElWPg0KPERJVj5vZiZuYnNwO3RoZSZuYnNwO3Byb2JsZW0sJm5ic3A7YnV0Jm5ic3A7SSZu YnNwO2Rvbid0Jm5ic3A7dGhpbmsmbmJzcDt0aGVyZSdzJm5ic3A7cmVhbGx5Jm5ic3A7YSZuYnNw O21ham9yJm5ic3A7ZGlmZmVyZW5jZTwvRElWPg0KPERJVj5iZXR3ZWVuJm5ic3A7dGhlJm5ic3A7 dHdvJm5ic3A7Y2FzZXMuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4NCjxESVY+Kioq KioqKioqKioqKioqKioqKioqKioqPC9ESVY+DQo8RElWPltEb25nXSBJZiBJIHVuZGVyc3RhbmQg eW91ciBjb21tZW50IGNvcnJlY3RseSwgSSB0aGluayB0aGVyZSBpcyBhIA0KbWlzdW5kZXJzdGFu ZGluZy4gPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JIGFncmVzcyB0aGF0IHdoZW4g YW55IHF1ZXJ5IGFjdGlvbiBoYXBwZW5zLCB0aGUmbmJzcDtpbmZvcm1hdGlvbiBvZiB0aGUgDQpx dWVyeSBzaG91bGQgPC9ESVY+DQo8RElWPmFscmVhZHkgaGF2ZSBiZWVuIHByb2R1Y2VkLiBUaHVz LCB0aGUgYW5zd2VyIGlzIGFsd2F5cyBpbiBwYXN0IHRpbWUuIDwvRElWPg0KPERJVj5CdXQgd2hh dCBJIGFtIHRyeWluZyB0byBzYXkgaW4gdGhlIGRyYWZ0IGlzIHRoYXQgd2hlbiZuYnNwO3NvdXJj ZSANCnRyYWNpbmcmbmJzcDtiZWhhdmlvciZuYnNwO2hhcHBlbnMsIDwvRElWPg0KPERJVj50aGUg c2Vzc2lvbiB0cmFuc2xhdGlvbiBiaW5kaW5nIGlzIHN0aWxsIGFjdGl2ZSBvbiB0aGUgQ0dOJm5i c3A7Ym94LiBUaGlzIA0KY2FzZSBpcyZuYnNwO2NhbGxlZDwvRElWPg0KPERJVj5yZWxhdGltZSB0 cmFjaW5nLjwvRElWPg0KPERJVj5UaGUgb3RoZXIgY2FzZSBpcyBub24tcmVsYXRpbWUgdHJhY2lu Zy4gQmVjYXVzZSB0aGUgbG9nIHNlcnZlciANCnN0b3JlcyZuYnNwO3RoZSBoaXN0b3J5IDwvRElW Pg0KPERJVj5pbmZvcm1hdGlvbiwgd2hlbiB0aGUgdHJhY2luZyBhY3Rpb24gaGFwcGVucywgdGhl IHNlc3Npb24gYmluZGluZyBoYXMgYmVlbiANCmRlbGV0ZWQmbmJzcDtvbjwvRElWPg0KPERJVj5D R04gYm94LiZuYnNwOyZuYnNwOzwvRElWPg0KPERJVj4qKioqKioqKioqKioqKioqKioqKioqKio8 L0RJVj48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPmlmJm5ic3A7eW91Jm5ic3A7d2Vy ZSZuYnNwO2xvb2tpbmcmbmJzcDtmb3ImbmJzcDthJm5ic3A7bG9jYXRpb24mbmJzcDtmb3ImbmJz cDt0aGlzJm5ic3A7d29yayZuYnNwO0kmbmJzcDt3b3VsZCZuYnNwO2NvbnNpZGVyPC9ESVY+DQo8 RElWPnRyYW5zcG9ydCZuYnNwO2FuZCZuYnNwO3NwZWNpZmljYWxseSZuYnNwO2JlaGF2ZSZuYnNw O2FzJm5ic3A7cG90ZW50aWFsbHkmbmJzcDthcHByb3ByaWF0ZSZuYnNwO2xvY2F0aW9uPC9ESVY+ DQo8RElWPmZvciZuYnNwO3N1Y2guPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4qKioq KioqKioqKioqKioqKioqKioqKio8L0RJVj4NCjxESVY+W0RvbmddIEkga25vdyBzZXZlcmFsIGNh cnJpZXJzIGhhdmUgcHJvcG9zZWQgdGhlIHNvdXJjZSBhZGRyZXNzIHRyYWNpbmcgDQpyZXF1aXJl bWVudCA8L0RJVj4NCjxESVY+ZXhwbGljaXRseS4gVGhleSBhc2sgdGhlIENHTiB2ZW5kb3JzIGZv ciB0cmFjaW5nJm5ic3A7c29sdXRpb24gd2hlbiB0aGV5IA0KY29uc2lkZXIgZGVwbG95aW5nIDwv RElWPg0KPERJVj5OQVQ0NDQsIERTLUxpdGUgYW5kIE5BVDY0LiBCYXNlZCBvbiB0aGlzIHJlYXNv biwgaSB0aGluayBhIGd1aWRhbmNlIA0KZG9jdW1lbnQgbWF5IGJlIDwvRElWPg0KPERJVj5uZWVk ZWQuIDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+QWN0dWFsbHksIHRoZSBwcm9ibGVt IGhhcyBiZWVuIHBvaW50ZWQgb3V0IGluIA0KZHJhZnQtaWV0Zi12Nm9wcy12Ni1pbi1tb2JpbGUt bmV0d29ya3MtMDMuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5kcmFmdC1pZXRmLXY2 b3BzLXY2LWluLW1vYmlsZS1uZXR3b3Jrcy0wMyBzYXlzOjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+Jm5ic3A7Jm5ic3A7IEluIGFkZGl0aW9uIHRvIHRoZSBkZXZlbG9wbWVudHMgY2l0 ZWQgYWJvdmUsIE5BVCBwbGFjZW1lbnQgDQppczxCUj4mbmJzcDsmbmJzcDsgaW1wb3J0YW50IGZv ciBvdGhlciByZWFzb25zLiZuYnNwOyBBY2Nlc3MgbmV0d29ya3MgZ2VuZXJhbGx5IA0KbmVlZCB0 bzxCUj4mbmJzcDsmbmJzcDsgcHJvZHVjZSBuZXR3b3JrIGFuZCBzZXJ2aWNlIHVzYWdlIHJlY29y ZHMgZm9yIGJpbGxpbmcgDQphbmQgYWNjb3VudGluZy48QlI+Jm5ic3A7Jm5ic3A7IFRoaXMgaXMg dHJ1ZSBmb3IgbW9iaWxlIG5ldHdvcmtzIGFzIHdlbGwgd2hlcmUgDQoic3Vic2NyaWJlcjxCUj4m bmJzcDsmbmJzcDsgbWFuYWdlbWVudCIgZmVhdHVyZXMgKGkuZS4sIFFvUywgUG9saWN5LCBhbmQg QmlsbGluZyANCmFuZCBBY2NvdW50aW5nKTxCUj4mbmJzcDsmbmJzcDsgY2FuIGJlIGZhaXJseSBk ZXRhaWxlZC4mbmJzcDsgU2luY2UgYSBOQVQgDQppbnRyb2R1Y2VzIGEgYmluZGluZyBiZXR3ZWVu IHR3bzxCUj4mbmJzcDsmbmJzcDsgYWRkcmVzc2VzLCB0aGUgYmluZGluZ3MgDQp0aGVtc2VsdmVz IGJlY29tZSBuZWNlc3NhcnkgaW5mb3JtYXRpb24gZm9yPEJSPiZuYnNwOyZuYnNwOyBzdWJzY3Jp YmVyIA0KbWFuYWdlbWVudC4mbmJzcDsgRm9yIGluc3RhbmNlLCB0aGUgb2ZmZXJlZCBRb1Mgb24g cHJpdmF0ZSBJUHY0PEJSPiZuYnNwOyZuYnNwOyANCmFkZHJlc3MgYW5kIHRoZSAoc2hhcmVkKSBw dWJsaWMgSVB2NCBhZGRyZXNzIG1heSBuZWVkIHRvIGJlPEJSPiZuYnNwOyZuYnNwOyANCmNvcnJl bGF0ZWQgZm9yIGFjY291bnRpbmcgcHVycG9zZXMuJm5ic3A7IEFzIGFub3RoZXIgZXhhbXBsZSwg DQp0aGU8QlI+Jm5ic3A7Jm5ic3A7IEFwcGxpY2F0aW9uIFNlcnZlcnMgd2l0aGluIHRoZSBwcm92 aWRlciBuZXR3b3JrIG1heSBuZWVkIHRvIA0KdHJlYXQ8QlI+Jm5ic3A7Jm5ic3A7IHRyYWZmaWMg YmFzZWQgb24gcG9saWN5IHByb3ZpZGVkIGJ5IHRoZSBQQ1JGLiZuYnNwOyBJZiB0aGUgDQpJUCBh ZGRyZXNzIHNlZW48QlI+Jm5ic3A7Jm5ic3A7IGJ5IHRoZXNlIEFwcGxpY2F0aW9uIFNlcnZlcnMg aXMgbm90IHVuaXF1ZSwgdGhlIA0KUENSRiBuZWVkcyB0byBiZSBhYmxlPEJSPiZuYnNwOyZuYnNw OyB0byBpbnNwZWN0IHRoZSBOQVQgYmluZGluZyB0byBkaXNhbWJpZ3VhdGUgDQphbW9uZyB0aGUg aW5kaXZpZHVhbCBNTnMuPEJSPiZuYnNwOyZuYnNwOyBBbmQsIHRoZSBzdWJzY3JpYmVyIHNlc3Np b24gbWFuYWdlbWVudCANCmluZm9ybWF0aW9uIGFuZCB0aGUgc2VydmljZTxCUj4mbmJzcDsmbmJz cDsgdXNhZ2UgaW5mb3JtYXRpb24gYWxzbyBuZWVkIHRvIGJlIA0KY29ycmVsYXRlZCBpbiBvcmRl ciB0byBwcm9kdWNlPEJSPiZuYnNwOyZuYnNwOyBoYXJtb25pemVkIHJlY29yZHMuJm5ic3A7IA0K RnVydGhlcm1vcmUsIHRoZXJlIG1heSBiZSBsZWdhbCByZXF1aXJlbWVudHMgZm9yPEJSPiZuYnNw OyZuYnNwOyBzdG9yaW5nIHRoZSBOQVQgDQpiaW5kaW5nIHJlY29yZHMuJm5ic3A7IEluZGVlZCwg dGhlc2UgcHJvYmxlbXMgZGlzYXBwZWFyPEJSPiZuYnNwOyZuYnNwOyB3aXRoIHRoZSANCnRyYW5z aXRpb24gdG8gSVB2Ni4mbmJzcDsgRm9yIG5vdywgaXQgc3VmZmljZXMgdG8gc3RhdGUgdGhhdCBO QVQ8QlI+Jm5ic3A7Jm5ic3A7IA0KaW50cm9kdWNlcyBzdGF0ZSB3aGljaCBuZWVkcyB0byBiZSBj b3JyZWxhdGVkIGFuZCBwb3NzaWJseSANCnN0b3JlZDxCUj4mbmJzcDsmbmJzcDsgd2l0aCBvdGhl ciByb3V0aW5lIHN1YnNjcmliZXIgaW5mb3JtYXRpb24uPEJSPjxCUj48L0RJVj4NCjxESVY+SG93 ZXZlciwgdGhlIGFpbSBvZiBkcmFmdC16aGFuZy12Nm9wcy1jZ24tc291cmNlLXRyYWNlIGlzIGlu dHJvZHVjaW5nIA0KdGhlJm5ic3A7ZGVwbG95bWVudCA8L0RJVj4NCjxESVY+bW9kZWxzIG9mIHNv dXJjZSB0cmFjaW5nIHNvbHV0aW9uLiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+VGhhbmsgeW91LjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+KioqKioqKioqKioq KioqKioqKioqKioqPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JJm5ic3A7d291bGQm bmJzcDthbHNvJm5ic3A7ZW5jb3VyYWdlJm5ic3A7dGhlJm5ic3A7YXV0aG9ycyZuYnNwO3RvJm5i c3A7cG9uZGVyJm5ic3A7cmZjJm5ic3A7MjgwNCZuYnNwO3doZW4mbmJzcDtjb25zaWRlcmluZzwv RElWPg0KPERJVj5ob3cmbmJzcDthbmQmbmJzcDt1bmRlciZuYnNwO3doYXQmbmJzcDtjaXJjdW1z dGFuY2VzJm5ic3A7dGhlJm5ic3A7aWV0ZiZuYnNwO3dvdWxkJm5ic3A7dW5kZXJ0YWtlJm5ic3A7 dG8mbmJzcDtzdGFuZGFyZGl6ZTwvRElWPg0KPERJVj50aGUmbmJzcDtmdW5jdGlvbmFsaXR5Jm5i c3A7dGhlJm5ic3A7cHJvYmxlbSZuYnNwO3N0YXRlbWVudCZuYnNwO3JlcXVpcmVzLi4uPC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5UcmFuc3BvcnQmbmJzcDtBRCZuYnNwO2NvcGllZCZu YnNwO3RvJm5ic3A7Y2xvc2UmbmJzcDtsb29wLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj48L0ZP TlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_5Pwco46EAL1YTTGNiuvogQ)-- From rashmi@kth.se Thu Feb 17 06:00:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 365953A6B6C for ; Thu, 17 Feb 2011 06:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-oZCjQQhLX0 for ; Thu, 17 Feb 2011 06:00:02 -0800 (PST) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 4C5F53A6D0E for ; Thu, 17 Feb 2011 06:00:02 -0800 (PST) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 03E7D14D870 for ; Thu, 17 Feb 2011 15:00:02 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id QkEIdlrMKLyN for ; Thu, 17 Feb 2011 15:00:00 +0100 (CET) X-KTH-Auth: rashmi [193.10.66.109] X-KTH-mail-from: rashmi@kth.se X-KTH-rcpt-to: v6ops@ietf.org Received: from [127.0.0.1] (rashmi.sics.se [193.10.66.109]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 44BF914C133 for ; Thu, 17 Feb 2011 15:00:00 +0100 (CET) Message-ID: <4D5D29B6.6040004@kth.se> Date: Thu, 17 Feb 2011 14:59:18 +0100 From: Rashmi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "v6ops@ietf.org" References: <4D376481.3010406@kth.se> <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> In-Reply-To: <6D53D5D6-5659-41C9-82F6-0BB61E3CD69E@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 18 Feb 2011 08:43:08 -0800 Subject: [v6ops] Happy eyeballs - P value X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 14:00:06 -0000 Hello, I am Rashmi, a Master's thesis student at KTH, Stockholm. I am doing a thesis on implementing "happy eyeballs" on "Name-based sockets". To start with, I have managed to get both IPv6 and IPv4 addresses from the DNS server and successfully establish a TCP connection to both of them. To send data, I use the connection which gets connected first. However, I failed to understand the advantage of having a variable "P" (mentioned on Page 6 of "Happy Eyeballs: Trending Towards Success with Dual-Stack draft-wing-v6ops-happy-eyeballs-ipv6-01"). If we do not have a persistent connection, then what purpose does the value of variable "P" server? Please explain. Thanks. -- Regards, Rashmi Purushothama Master Student, KTH, Stockholm From fred@cisco.com Fri Feb 18 22:02:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94EE3A6D13 for ; Fri, 18 Feb 2011 22:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.458 X-Spam-Level: X-Spam-Status: No, score=-110.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3sxdE4fPMyV for ; Fri, 18 Feb 2011 22:02:22 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3E8223A6C7E for ; Fri, 18 Feb 2011 22:02:21 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB/sXk2rR7Ht/2dsb2JhbACmM3OgVps3hV4EhBZ1hwaDOw X-IronPort-AV: E=Sophos;i="4.62,191,1297036800"; d="scan'208";a="266311473" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 19 Feb 2011 06:02:56 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1J62phj022183; Sat, 19 Feb 2011 06:02:56 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Fri, 18 Feb 2011 22:02:56 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Fri, 18 Feb 2011 22:02:56 -0800 From: Fred Baker Date: Fri, 18 Feb 2011 22:02:42 -0800 To: IPv6 Operations Message-Id: <7ED17702-091A-4484-85BF-584C18B8FD6C@cisco.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Important dates X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 06:02:26 -0000 http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 We have asked for our usual two sessions, 2.5 hours and 2 hours in = length. With any luck neither of them will be on Friday :-) The IETF-80 = agenda should be sorted out by the fourth of March. The final date for submission of new (-00) drafts is 7 March. Final date = for updated documents is 14 March. With one exception (a testing report, = for which the proceedings will be the enduring documentation), any draft = that will be discussed in this working group at IETF-80 needs a draft = posted since IETF-79, and should have corresponded with = v6ops-chairs@tools.ietf.org on the topic. Our final date to post the working group agenda is 16 March. I will post = a preliminary agenda on 7 March and repost on 14 March; these will be = for comment. early bird (reduced price) registration cut-off is 18 March. =95 2011-03-27 - 2011-04-01: 80th IETF Meeting in Prague, Czech = Republic. "Be there or be square", as my daughter tells me...= From joelja@bogus.com Sun Feb 20 15:27:07 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB18B3A6E02 for ; Sun, 20 Feb 2011 15:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.042 X-Spam-Level: X-Spam-Status: No, score=-102.042 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2Vf0i7mm6L8 for ; Sun, 20 Feb 2011 15:27:07 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id E01543A6DDA for ; Sun, 20 Feb 2011 15:27:06 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p1KNRgAR022957 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sun, 20 Feb 2011 23:27:44 GMT (envelope-from joelja@bogus.com) Message-ID: <4D61A36E.4030708@bogus.com> Date: Sun, 20 Feb 2011 15:27:42 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPv6 Ops WG References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> In-Reply-To: <4D5814F9.3070800@bogus.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sun, 20 Feb 2011 23:27:44 +0000 (UTC) Subject: [v6ops] comments: Re: WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 23:27:08 -0000 So, I kinda slacked on my own deadline. I have reviewed the document and I think structurally and content-wise it's pretty close to ready if not outright go to go, I have kind of a lot of edits which I will include in a seperate email. in section 2 the last paragraph is sufficiently obtuse that without reading section 6 to which it refers you have no idea what it means. Finally, DNS whitelisting can be deployed in two primary ways: universally on a global basis, or on an ad hoc basis. These two potential deployment models are described in Section 6. In section 6 I would swap the order of 6.2 and 6.1 since the later is what is happening and sems most likely to remain the case for the forseeable future. On 2/13/11 9:29 AM, Joel Jaeggli wrote: > The halfway point has been reached, please get your feedback in by > monday the 21st... > > > On 2/6/11 7:35 PM, Joel Jaeggli wrote: >> This announcement is to serve as the beginning of the WGLC for: >> >> draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 >> >> http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 >> >> WGLC runs from Monday Feb 7th to Monday Feb 21st. >> >> The 01 version of this document received a lot of good feedback on this >> list which has been incorporated into this version of the draft. >> >> joelja >> _______________________________________________ >> 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 joelja@bogus.com Sun Feb 20 15:35:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9A03A6F0E for ; Sun, 20 Feb 2011 15:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.037 X-Spam-Level: X-Spam-Status: No, score=-102.037 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTbNDQw2XDvw for ; Sun, 20 Feb 2011 15:35:05 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 204333A6CFB for ; Sun, 20 Feb 2011 15:35:04 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p1KNZhF7023463 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sun, 20 Feb 2011 23:35:44 GMT (envelope-from joelja@bogus.com) Message-ID: <4D61A54F.2090006@bogus.com> Date: Sun, 20 Feb 2011 15:35:43 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPv6 Ops WG References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> In-Reply-To: <4D61A36E.4030708@bogus.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sun, 20 Feb 2011 23:35:44 +0000 (UTC) Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 23:35:06 -0000 So far on this Last call we've heard from: Brian Carpenter Fred Baker (wg chair) Joel Jaeggli (wg chair) Jason Livingood (author) Deadline is end of monday everywhere to get your .02 in. On 2/20/11 3:27 PM, Joel Jaeggli wrote: > On 2/13/11 9:29 AM, Joel Jaeggli wrote: >> The halfway point has been reached, please get your feedback in by >> monday the 21st... >> >> >> On 2/6/11 7:35 PM, Joel Jaeggli wrote: >>> This announcement is to serve as the beginning of the WGLC for: >>> >>> draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 >>> >>> http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 >>> >>> WGLC runs from Monday Feb 7th to Monday Feb 21st. >>> >>> The 01 version of this document received a lot of good feedback on this >>> list which has been incorporated into this version of the draft. >>> >>> joelja >>> _______________________________________________ >>> 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 victor.kuarsingh@gmail.com Sun Feb 20 15:50:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D5AE3A6F76 for ; Sun, 20 Feb 2011 15:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo5rxt3k9Dx4 for ; Sun, 20 Feb 2011 15:50:35 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 69BA53A6EAC for ; Sun, 20 Feb 2011 15:50:35 -0800 (PST) Received: by yxd39 with SMTP id 39so657177yxd.31 for ; Sun, 20 Feb 2011 15:51:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-type; bh=sjDAA+41bTUVSAFrenXTCcToTPSkD9Go++PwYeXDggk=; b=CMme/e5mKRtPj8/dwDE0Zk0W6HFerBdIotB803mxL0ta58inWyfh9OxfPlDnwNm/bj P5Y5WfJx/FDpPUTVrnw6e2uVaiREj9BkFqg/QuYjQdHUoRu3GUr0GCslDkXnT1xa3p3K sqg/IKhE7MDbfi1PC18bQKOfCbTsCgcAHQXCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; b=AFKzwd7MJFyjqLdRg0InMxSTOOL9ZcMmd3NQgfcrdJTjqOS4TzBkO7IZ6pk5HGA/0L UEf1FcD+dM1QAXjpXsroRGXzAF0kphE9jG7VLUrMYqw/Z5n4LlN0sFvW5GBe5bKQOyBh 22gedfMtqD+xSgzikhGFIcPNpZOiNi0eJURlw= Received: by 10.150.44.12 with SMTP id r12mr922327ybr.428.1298245875307; Sun, 20 Feb 2011 15:51:15 -0800 (PST) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id d3sm1230405ybi.5.2011.02.20.15.51.13 (version=SSLv3 cipher=OTHER); Sun, 20 Feb 2011 15:51:14 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 20 Feb 2011 18:58:02 -0500 From: Victor Kuarsingh To: Message-ID: Thread-Topic: Regarding 6to4 PMT Draft Update Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3381073086_1620724" Subject: [v6ops] Regarding 6to4 PMT Draft Update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 23:50:36 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3381073086_1620724 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Group, In light of some feedback in Bejing, I have updated the draft to concentrate on the CGN/NAT444 use case related to broken 6to4(RFC3068) based operation. New/updated draft - draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-01 I know there has been much discussion on the list related to both Brian's advisory draft (draft-carpenter-v6ops-6to4-teredo-advisory-01) and Ole's newer draft which seeks to move 6to4 to historic (draft-troan-v6ops-6to4-to-historic-00). I am also well aware of some of the negative comments made. I will attempt to have a draft for Prague which documents the findings from testing related to PMT (only the facts). We are currently testing with code which runs on a 6to4 relay. Lightweight and almost no cost delta to running 6to4 on it's own. Regards, Victor K --B_3381073086_1620724 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Group,

<= div>In light of some feedback in Bejing, I have updated the draft to concent= rate on the CGN/NAT444 use case related to broken 6to4(RFC3068) based operat= ion.  New/updated draft - draft-kuarsingh-v6ops-6to4-provider-mana= ged-tunnel-01

I know there has been much discussion= on the list related to both Brian's advisory draft (draft-carpenter-v6ops-6= to4-teredo-advisory-01) and Ole's newer draft which seeks to move 6to4 to hi= storic (draft-troan-v6ops-6to4-to-historic-00).

I a= m also well aware of some of the negative comments made.  I will attemp= t to have a draft for Prague which documents the findings from testing relat= ed to PMT (only the facts).   We are currently testing with code which = runs on a 6to4 relay.  Lightweight and almost no cost delta to running = 6to4 on it's own.

Regards,

Victor K --B_3381073086_1620724-- From jason_livingood@cable.comcast.com Mon Feb 21 06:52:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27EFC3A7118 for ; Mon, 21 Feb 2011 06:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.695 X-Spam-Level: X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=-0.961, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2ZtqeNRVD-W for ; Mon, 21 Feb 2011 06:52:46 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 068273A7117 for ; Mon, 21 Feb 2011 06:52:45 -0800 (PST) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.26712197; Mon, 21 Feb 2011 07:17:31 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Mon, 21 Feb 2011 09:05:53 -0500 From: "Livingood, Jason" To: Joel Jaeggli , IPv6 Ops WG Thread-Topic: [v6ops] comments: Re: WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 Thread-Index: AQHL0dBzlo2/PPYm4kSlv458L3vjxg== Date: Mon, 21 Feb 2011 14:05:52 +0000 Message-ID: In-Reply-To: <4D61A36E.4030708@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.12] Content-Type: multipart/alternative; boundary="_000_C987D62F19820jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: Re: [v6ops] comments: Re: WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 14:52:48 -0000 --_000_C987D62F19820jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Inline below. And thank you for your review! I'll wait to see if any other = minor tweaks are suggested today and then include this in a minor =9603 upd= ate based on any other WGLC suggestions. --JL I have reviewed the document and I think structurally and content-wise it's pretty close to ready if not outright go to go, I have kind of a lot of edits which I will include in a seperate email. [JL] I'll address those in a separate email later today. in section 2 the last paragraph is sufficiently obtuse that without reading section 6 to which it refers you have no idea what it means. Finally, DNS whitelisting can be deployed in two primary ways: universally on a global basis, or on an ad hoc basis. These two potential deployment models are described in Section 6. [JL] Good point. This now reads: Finally, DNS whitelisting can be deployed in two primary ways: universally = on a global basis, or on an ad hoc basis. Deployment on a universal deploym= ent basis means that DNS whitelisting is implemented on all authoritative D= NS servers, across the entire Internet. In contrast, deployment on an ad ho= c basis means that only some authoritative DNS servers, and perhaps even on= ly a few, implement DNS whitelisting. These two potential deployment models= are described in Section 6. In section 6 I would swap the order of 6.2 and 6.1 since the later is what is happening and sems most likely to remain the case for the forseeable future. [JL] Those sections will be reversed =96 good suggestion. Thanks again! Jason On 2/13/11 9:29 AM, Joel Jaeggli wrote: The halfway point has been reached, please get your feedback in by monday the 21st... On 2/6/11 7:35 PM, Joel Jaeggli wrote: This announcement is to serve as the beginning of the WGLC for: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implicatio= ns-02 WGLC runs from Monday Feb 7th to Monday Feb 21st. The 01 version of this document received a lot of good feedback on this list which has been incorporated into this version of the draft. joelja --_000_C987D62F19820jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Inline below. And thank you for your review! I'll wait to see if any o= ther minor tweaks are suggested today and then include this in a minor =960= 3 update based on any other WGLC suggestions.

--JL

I have reviewed the document and I think structurally and content-wise=
it's pretty close to ready if not outright go to go, I have kind of a<= /div>
lot of edits which I will include in a seperate email.

[JL] I'll address those in a separate email later today. 

in section 2 the last paragraph is sufficiently obtuse that without
reading section 6 to which it refers you have no idea what it means.


   Finally, DNS whitelisting can be deployed in two primary = ways:
   universally on a global basis, or on an ad hoc basis.&nbs= p; These two
   potential deployment models are described in Section 6.

[JL] Good point. This now reads:

Finally, DNS white= listing can be deployed in two primary ways: universally on a global basis,= or on an ad hoc basis. Deployment on a universal deployment basis means that DNS whitelisting is implemented on= all authoritative DNS servers, across the entire Internet. In contrast, de= ployment on an ad hoc basis means that only some authoritative DNS servers,= and perhaps even only a few, implement DNS whitelisting. These two potential deployment models are described in&n= bsp;Section 6.

In section 6 I would swap the order of 6.2 and 6.1 since the later is<= /div>
what is happening and sems most likely to remain the case for the
forseeable future.

[JL] Those sections will be reversed =96 good suggestion.

Thanks again!
Jason





On 2/13/11 9:29 AM, Joel Jaeggli wrote:
The halfway point has been reached, please get your feedback in by
monday the 21st...
On 2/6/11 7:35 PM, Joel Jaeggli wrote:
This announcement is to serve as the beginning of the WGLC for:

draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02


WGLC runs from Monday Feb 7th to Monday Feb 21st.

The 01 version of this document received a lot of good feedback on thi= s
list which has been incorporated into this version of the draft.

joelja
--_000_C987D62F19820jasonlivingoodcablecomcastcom_-- From K.Fleischhauer@telekom.de Mon Feb 21 07:28:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02AC93A6DD8 for ; Mon, 21 Feb 2011 07:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYirzwK78LAk for ; Mon, 21 Feb 2011 07:28:06 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 2D2D13A6D03 for ; Mon, 21 Feb 2011 07:28:05 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 21 Feb 2011 16:28:40 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.24]) by he110890 ([10.134.92.131]) with mapi; Mon, 21 Feb 2011 16:28:40 +0100 From: To: , Date: Mon, 21 Feb 2011 16:28:39 +0100 Thread-Topic: [v6ops] Soliciting feedback on draft-livingood-dns-whitelisting-implications Thread-Index: AQHLYZZsVCE0+zqIz0+l2xjka9peKJMs6OYAgLXWlQCAKizzgA== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D010C6DB4CF@HE111648.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Soliciting feedback on draft-livingood-dns-whitelisting-implications X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 15:28:08 -0000 Dear Jason, section "7.1 Architectural Implications" should at least contain a hint that with DNS-Whitelisting from an ISP perspective the usage of the Dual-Stack approach as defined in section 2 of RFC4177 as "the most straightforward way for IPv6 nodes to remain compatible with IPv4-only nodes" is only very limited applicable: 1. ISP have to provide different DNS resolver for different customer groups (e.g. IPv4-only customers and Dual-Stack customers/IPv6-only customers), 2. During the dial-in process the membership of an access device/customer to the above mentioned groups has to be identified und depending on the result the DNS resolver addresses (IPv4) has to be provisioned. 3. To meet these requirements a lot of finalized standards has to be review= ed and maybe revised. All this would lead to additional delay and effort for introducing IPv6. Kind regards Karsten Karsten Fleischhauer Deutsche Telekom Netzproduktion GmbH From d.sturek@att.net Mon Feb 21 08:54:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E19C3A7131 for ; Mon, 21 Feb 2011 08:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67cP0SoSWM5B for ; Mon, 21 Feb 2011 08:53:59 -0800 (PST) Received: from nm30.bullet.mail.ac4.yahoo.com (nm30.bullet.mail.ac4.yahoo.com [98.139.52.227]) by core3.amsl.com (Postfix) with SMTP id 963513A712B for ; Mon, 21 Feb 2011 08:53:59 -0800 (PST) Received: from [98.139.52.196] by nm30.bullet.mail.ac4.yahoo.com with NNFMP; 21 Feb 2011 16:54:41 -0000 Received: from [98.139.52.159] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 21 Feb 2011 16:54:41 -0000 Received: from [127.0.0.1] by omp1042.mail.ac4.yahoo.com with NNFMP; 21 Feb 2011 16:54:41 -0000 X-Yahoo-Newman-Id: 586135.86065.bm@omp1042.mail.ac4.yahoo.com Received: (qmail 32227 invoked from network); 21 Feb 2011 16:54:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1298307281; bh=Qn9MhWWTTcE9KERfwWJNhvC5MsDpSgQVDHbp2RT0tDQ=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=a7EmndEqzvs+ML6T1eGNSrdxeX7H0lbY3HwhxoeknwXqfI2AqNGilD92zZCblQ69FtbtZdaI0KpvnMw5BDsQ2/nJLx54dbpYevjNUJwg7rFkaE3jO2uCCPmBimjj7W6BxRQQfcymLf7dHtAjSyzUzCh4ablc1aTuKkRbOMDU950= Received: from Studio (d.sturek@174.78.56.227 with login) by smtp102.sbc.mail.re3.yahoo.com with SMTP; 21 Feb 2011 08:54:37 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 5rr5iuwVM1npJmAEd8u9XvOUdqppmVY91W3MY4ONyzoPjCF hLNSJxtTIMjJiV7i2kWwMk3KLt2XWnMzHuG.jEN_Gt_TAPDzL5AfEfLdCbzX HEOlo1oyutpl0ZdQHyRQOYDky.CektwDgbCpn8ct83K9CslinTR.uwpVJ905 OnLiZORH1m2BtFLM3i4UoTCOOf7EnUPMILP6yT6tZ4bhDc5gTxpIHSDgRiqd jKnFxnzHEVpH0ER_Jd3Oe54uP2D5lzFu_lj1ZMER_OqvWsk3KhOo_utYwONy FCAw.48nfYRQpjgu1jdPWY_9GsvAZOI2fhbk- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Fred Baker'" , "'IPv6 Operations'" References: <7ED17702-091A-4484-85BF-584C18B8FD6C@cisco.com> In-Reply-To: <7ED17702-091A-4484-85BF-584C18B8FD6C@cisco.com> Date: Mon, 21 Feb 2011 08:54:35 -0800 Message-ID: <002201cbd1e8$05abe3c0$1103ab40$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvP+q2Ci4uwT42wTi+l8JUuTC57dAB66zTw Content-Language: en-us Cc: kerlyn2001@gmail.com Subject: Re: [v6ops] Important dates X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 16:54:00 -0000 Hi Fred, The Smart Energy 2.0 team on resource discovery (Kerry Lynn, Ralph Droms, Tom Herbst and myself) would like to request a total of 15 minutes at the IETF-80 v6ops meeting to discuss a series of I-Ds we will be submitting (and in some cases refining) for use with SE 2.0. Here are the topics for the single time block: 1) ULA address allocation - We plan to use ULAs in our deployment to enable multicast DNS (m-DNS) resource discovery 2) ULA prefix delegation/proxy - At IETF-79, we were to work with the advanced v6ops draft (draft-wbeebee-v6ops-ipv6-cpe-router-bis-04) on this topic but I think it did not progress due to other pressing issues in that draft. Unfortunately, this topic will be front and center when the SE 2 solution deploys next year so we will at least put a big target out that people can complain about :-) Don -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker Sent: Friday, February 18, 2011 10:03 PM To: IPv6 Operations Subject: [v6ops] Important dates http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 We have asked for our usual two sessions, 2.5 hours and 2 hours in length. With any luck neither of them will be on Friday :-) The IETF-80 agenda should be sorted out by the fourth of March. The final date for submission of new (-00) drafts is 7 March. Final date for updated documents is 14 March. With one exception (a testing report, for which the proceedings will be the enduring documentation), any draft that will be discussed in this working group at IETF-80 needs a draft posted since IETF-79, and should have corresponded with v6ops-chairs@tools.ietf.org on the topic. Our final date to post the working group agenda is 16 March. I will post a preliminary agenda on 7 March and repost on 14 March; these will be for comment. early bird (reduced price) registration cut-off is 18 March. . 2011-03-27 - 2011-04-01: 80th IETF Meeting in Prague, Czech Republic. "Be there or be square", as my daughter tells me... _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From jason_livingood@cable.comcast.com Mon Feb 21 10:15:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D773A7136 for ; Mon, 21 Feb 2011 10:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.995 X-Spam-Level: X-Spam-Status: No, score=-105.995 tagged_above=-999 required=5 tests=[AWL=2.467, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VExnC2DjfdeZ for ; Mon, 21 Feb 2011 10:15:03 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 90BC03A7131 for ; Mon, 21 Feb 2011 10:15:03 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.114378482; Mon, 21 Feb 2011 13:15:42 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Mon, 21 Feb 2011 13:15:42 -0500 From: "Livingood, Jason" To: "K.Fleischhauer@telekom.de" , "v6ops@ietf.org" Thread-Topic: [v6ops] Soliciting feedback on draft-livingood-dns-whitelisting-implications Thread-Index: AQHLYZZsVCE0+zqIz0+l2xjka9peKJMs6OYAgLXWlQCAKizzgIAANxgA Date: Mon, 21 Feb 2011 18:15:41 +0000 Message-ID: In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D010C6DB4CF@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.12] Content-Type: multipart/alternative; boundary="_000_C9880DE4199C0jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: Re: [v6ops] Soliciting feedback on draft-livingood-dns-whitelisting-implications X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 18:15:05 -0000 --_000_C9880DE4199C0jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Karsten and thanks for your review! I think you mean RFC 4213, which I will made a reference to in Section 7.1.= If I have gotten that wrong, please say so. What I propose adding to 7.1 = is the following: //start// Also, it is possible that DNS whitelisting could affect some of the archite= ctural assumptions which underlie parts of Section 2 of [RFC4213] which outlines the dual stack a= pproach to the IPv6 transition. DNS whitelisting could modify the behavior = of the DNS, as described in Section 2.2 of [RFC4213] and could require different sets of DNS serv= ers to be used for hosts that are (using terms from that document) IPv6/IPv= 4 nodes, IPv4-only nodes, and IPv6-only nodes. As such, broad use of DNS wh= itelisting may necessitate the review and/or revision of standards document= s which describe dual-stack and IPv6 operating modes, dual-stack architectu= re generally, and IPv6 transition methods, including but not limited to [RF= C4213]. //end// I'll incorporate your suggestions into a -03 version shortly, unless you wi= sh to see changes to what I proposed. Thanks Jason On 2/21/11 10:28 AM, "K.Fleischhauer@telekom.de" > wrote: Dear Jason, section "7.1 Architectural Implications" should at least contain a hint that with DNS-Whitelisting from an ISP perspective the usage of the Dual-Stack approach as defined in section 2 of RFC4177 as "the most straightforward way for IPv6 nodes to remain compatible with IPv4-only nodes" is only very limited applicable: 1. ISP have to provide different DNS resolver for different customer groups (e.g. IPv4-only customers and Dual-Stack customers/IPv6-only customers), 2. During the dial-in process the membership of an access device/customer to the above mentioned groups has to be identified und depending on the result the DNS resolver addresses (IPv4) has to be provisioned. 3. To meet these requirements a lot of finalized standards has to be reviewed and maybe revised. All this would lead to additional delay and effort for introducing IPv6. Kind regards Karsten Karsten Fleischhauer Deutsche Telekom Netzproduktion GmbH --_000_C9880DE4199C0jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Karsten and thanks for your review! 

I think you mean RFC 4213, which I will made a reference to in Section= 7.1.  If I have gotten that wrong, please say so. What I propose addi= ng to 7.1 is the following:

//start//
[RFC4213] which outlines the dual stack approach to the IPv6 transition. DNS whitelisting could mod= ify the behavior of the DNS, as described in Section 2.2 of [RFC4213]&= nbsp;and could require different sets of DNS servers to be used for hosts that are = (using terms from that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6= -only nodes. As such, broad use of DNS whitelisting may necessitate the rev= iew and/or revision of standards documents which describe dual-stack and IPv6 operating modes, dual-stack a= rchitecture generally, and IPv6 transition methods, including but not limit= ed to [RFC4213].
//end//

I'll incorporate your suggestions into a -03 version shortly, unless y= ou wish to see changes to what I proposed. 

Thanks
Jason

On 2/21/11 10:28 AM, "K.Fleischhauer@telekom.de"

Dear Jason,

section "7.1 Architectural Implications" should at least
contain a hint that with DNS-Whitelisting from an ISP perspective
the usage of the Dual-Stack approach as defined in section 2 of
RFC4177 as "the most straightforward way for IPv6 nodes to remain=
compatible with IPv4-only nodes" is only very limited applicable:=

1. ISP have to provide different DNS resolver for different customer <= /div>
groups
   (e.g. IPv4-only customers and Dual-Stack customers/IPv6-o= nly
customers),
2. During the dial-in process the membership of an access device/custo= mer
   to the above mentioned groups has to be identified und de= pending
   on the result the DNS resolver addresses (IPv4) has to be= provisioned.
3. To meet these requirements a lot of finalized standards has to be <= /div>
reviewed
   and maybe revised.

All this would lead to additional delay and effort for introducing IPv= 6.


Kind regards

Karsten

Karsten Fleischhauer

Deutsche Telekom Netzproduktion GmbH
--_000_C9880DE4199C0jasonlivingoodcablecomcastcom_-- From dougb@dougbarton.us Mon Feb 21 10:50:59 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F763A70FD for ; Mon, 21 Feb 2011 10:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNsGX-OpfYAk for ; Mon, 21 Feb 2011 10:50:51 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 4CDF63A6FEF for ; Mon, 21 Feb 2011 10:50:51 -0800 (PST) Received: (qmail 24480 invoked by uid 399); 21 Feb 2011 18:51:28 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 21 Feb 2011 18:51:28 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D62B42E.9020003@dougbarton.us> Date: Mon, 21 Feb 2011 10:51:26 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joel Jaeggli References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> <4D61A54F.2090006@bogus.com> In-Reply-To: <4D61A54F.2090006@bogus.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 18:51:00 -0000 On 02/20/2011 15:35, Joel Jaeggli wrote: > So far on this Last call we've heard from: > > Brian Carpenter > Fred Baker (wg chair) > Joel Jaeggli (wg chair) > Jason Livingood (author) > > Deadline is end of monday everywhere to get your .02 in. With respect to the authors I think this draft is a bad idea, and I oppose it moving forward. 1. The entire draft takes on the "You're doing it wrong!" tone that alienates operators from those in the IPv6 advocacy community that actually have something useful to contribute. 2. It purports objectivity about "why some would object" to the practice, but (IMO) has a clear editorial slant as to whitelisting being bad. 3. Most of Section 4 makes no sense at all. I don't see anyone adding v6-only hosts to "highly trafficked sites" any time soon. 4. The last paragraph of Section 4 is a complete red herring. It does not matter what the level of v4 impairment is relative to v6 impairment. The problem that sites are trying to solve is people who CAN reach the site over v4 who have a degraded experience after v6 is enabled. The 0.078% (or 1/2000 to use Google's number) is not the percentage of the total number of potential Internet users, it's the total of users they _already have_. 5. Section 5 basically hand-waves the fact that operators are already doing lots of other things with DNS that make whitelisting essentially a drop in the bucket. 6. Section 7.1 is completely irrelevant. The end-to-end ship sailed years ago. Simply put, if published this draft will do more harm than good. The major sites are already moving forward on wider v6 deployment, including Google, the site that popularized whitelisting. (See http://isoc.org/wp/worldipv6day/, et al) OTOH, sites that genuinely believe that they need to use this technique are going to use it whether this document is released or not. "It works for Google" is a much more persuasive line of reasoning. Releasing this now makes us look like a bunch of old ladies wagging our fingers at recalcitrant children. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From joelja@bogus.com Mon Feb 21 11:01:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954433A7146 for ; Mon, 21 Feb 2011 11:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2clacFTx4bv1 for ; Mon, 21 Feb 2011 11:01:09 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 08E433A7155 for ; Mon, 21 Feb 2011 11:01:08 -0800 (PST) Received: from joelja-mac.local (adsl-99-173-15-226.dsl.pltn13.sbcglobal.net [99.173.15.226]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p1LJ1j2m084306 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 21 Feb 2011 19:01:46 GMT (envelope-from joelja@bogus.com) Message-ID: <4D62B699.3040102@bogus.com> Date: Mon, 21 Feb 2011 11:01:45 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Doug Barton References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> <4D61A54F.2090006@bogus.com> <4D62B42E.9020003@dougbarton.us> In-Reply-To: <4D62B42E.9020003@dougbarton.us> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Mon, 21 Feb 2011 19:01:47 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 19:01:10 -0000 On 2/21/11 10:51 AM, Doug Barton wrote: > On 02/20/2011 15:35, Joel Jaeggli wrote: >> So far on this Last call we've heard from: >> >> Brian Carpenter >> Fred Baker (wg chair) >> Joel Jaeggli (wg chair) >> Jason Livingood (author) >> >> Deadline is end of monday everywhere to get your .02 in. > > With respect to the authors I think this draft is a bad idea, and I > oppose it moving forward. I proposed a series of edits (sent to jason first due to their length) that neutralize the tone a bit but without I think altering the content. I think that the characterization of the problems with a whitelisting approach is useful and important. It's going to (has) happened anyway and it's not a "we told you so" it's "these are the issues you have to contend with." > 1. The entire draft takes on the "You're doing it wrong!" tone that > alienates operators from those in the IPv6 advocacy community that > actually have something useful to contribute. > 2. It purports objectivity about "why some would object" to the > practice, but (IMO) has a clear editorial slant as to whitelisting being > bad. > 3. Most of Section 4 makes no sense at all. I don't see anyone adding > v6-only hosts to "highly trafficked sites" any time soon. > 4. The last paragraph of Section 4 is a complete red herring. It does > not matter what the level of v4 impairment is relative to v6 impairment. > The problem that sites are trying to solve is people who CAN reach the > site over v4 who have a degraded experience after v6 is enabled. The > 0.078% (or 1/2000 to use Google's number) is not the percentage of the > total number of potential Internet users, it's the total of users they > _already have_. I my personal belief is that if anything it represents an under-sampling of the problems that the userbase will experience. I'm not going to try and back that up with emperical data since my sample is way too small to be relevant. > 5. Section 5 basically hand-waves the fact that operators are already > doing lots of other things with DNS that make whitelisting essentially a > drop in the bucket. > 6. Section 7.1 is completely irrelevant. The end-to-end ship sailed > years ago. > > Simply put, if published this draft will do more harm than good. The > major sites are already moving forward on wider v6 deployment, including > Google, the site that popularized whitelisting. (See > http://isoc.org/wp/worldipv6day/, et al) OTOH, sites that genuinely > believe that they need to use this technique are going to use it whether > this document is released or not. "It works for Google" is a much more > persuasive line of reasoning. Releasing this now makes us look like a > bunch of old ladies wagging our fingers at recalcitrant children. > > > Doug > From dougb@dougbarton.us Mon Feb 21 11:05:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7273A7152 for ; Mon, 21 Feb 2011 11:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiKuegbYPaX1 for ; Mon, 21 Feb 2011 11:05:38 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id D03503A714D for ; Mon, 21 Feb 2011 11:05:37 -0800 (PST) Received: (qmail 18499 invoked by uid 399); 21 Feb 2011 19:06:16 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 21 Feb 2011 19:06:16 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D62B7A7.1000108@dougbarton.us> Date: Mon, 21 Feb 2011 11:06:15 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joel Jaeggli References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> <4D61A54F.2090006@bogus.com> <4D62B42E.9020003@dougbarton.us> <4D62B699.3040102@bogus.com> In-Reply-To: <4D62B699.3040102@bogus.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 19:05:39 -0000 On 02/21/2011 11:01, Joel Jaeggli wrote: > On 2/21/11 10:51 AM, Doug Barton wrote: >> On 02/20/2011 15:35, Joel Jaeggli wrote: >>> So far on this Last call we've heard from: >>> >>> Brian Carpenter >>> Fred Baker (wg chair) >>> Joel Jaeggli (wg chair) >>> Jason Livingood (author) >>> >>> Deadline is end of monday everywhere to get your .02 in. >> >> With respect to the authors I think this draft is a bad idea, and I >> oppose it moving forward. > > I proposed a series of edits (sent to jason first due to their length) > that neutralize the tone a bit but without I think altering the content. > I think that the characterization of the problems with a whitelisting > approach is useful and important. It's going to (has) happened anyway > and it's not a "we told you so" it's "these are the issues you have to > contend with." I would be willing to reconsider my position after reviewing a new draft, but I admit to a strong bias. More to the point, I don't think that anyone has deployed this solution without thinking through the implications (certainly not on the larger sites) which is one of the reasons I think that publishing the draft at all is at best counterproductive. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From fred@cisco.com Mon Feb 21 11:26:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD0AE3A712A for ; Mon, 21 Feb 2011 11:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.167 X-Spam-Level: X-Spam-Status: No, score=-110.167 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEjvKnGPQAdQ for ; Mon, 21 Feb 2011 11:26:14 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A8E2A3A6F77 for ; Mon, 21 Feb 2011 11:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2510; q=dns/txt; s=iport; t=1298316417; x=1299526017; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=nkHUNkOp4hL5z9stigj2WW/slyOiWPTOOcAAobNzZ7k=; b=YEKcGDhCnUypez7bwTJukGCb4Rv9t/3neNC9ttjJjgJ4pZ2DQTMDV549 Z6GdEG867/4iX/PfFRSLske3RLzaYu4UnbArjTxG+sh6R8erWxHlO266B Rw3bWXgKhz62JW7cFrxpjSJ49Re35MHi9WGPNlMInLkpZRaDMI6a1xa87 M=; X-IronPort-AV: E=Sophos;i="4.62,201,1297036800"; d="scan'208";a="263241228" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 21 Feb 2011 19:26:57 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1LJPhuK025172; Mon, 21 Feb 2011 19:26:56 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Mon, 21 Feb 2011 11:26:56 -0800 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Mon, 21 Feb 2011 11:26:56 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <002201cbd1e8$05abe3c0$1103ab40$@sturek@att.net> Date: Mon, 21 Feb 2011 11:26:56 -0800 Message-Id: References: <7ED17702-091A-4484-85BF-584C18B8FD6C@cisco.com> <002201cbd1e8$05abe3c0$1103ab40$@sturek@att.net> To: X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: 'IPv6 Operations' , kerlyn2001@gmail.com Subject: Re: [v6ops] Important dates X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 19:26:15 -0000 You'll have a posted internet draft, right? On Feb 21, 2011, at 8:54 AM, Don Sturek wrote: > Hi Fred, >=20 > The Smart Energy 2.0 team on resource discovery (Kerry Lynn, Ralph = Droms, > Tom Herbst and myself) would like to request a total of 15 minutes at = the > IETF-80 v6ops meeting to discuss a series of I-Ds we will be = submitting (and > in some cases refining) for use with SE 2.0. Here are the topics for = the > single time block: > 1) ULA address allocation - We plan to use ULAs in our deployment to = enable > multicast DNS (m-DNS) resource discovery > 2) ULA prefix delegation/proxy - At IETF-79, we were to work with the > advanced v6ops draft (draft-wbeebee-v6ops-ipv6-cpe-router-bis-04) on = this > topic but I think it did not progress due to other pressing issues in = that > draft. Unfortunately, this topic will be front and center when the SE = 2 > solution deploys next year so we will at least put a big target out = that > people can complain about :-) >=20 > Don >=20 >=20 >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of > Fred Baker > Sent: Friday, February 18, 2011 10:03 PM > To: IPv6 Operations > Subject: [v6ops] Important dates >=20 > http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 >=20 > We have asked for our usual two sessions, 2.5 hours and 2 hours in = length. > With any luck neither of them will be on Friday :-) The IETF-80 agenda > should be sorted out by the fourth of March. >=20 > The final date for submission of new (-00) drafts is 7 March. Final = date for > updated documents is 14 March. With one exception (a testing report, = for > which the proceedings will be the enduring documentation), any draft = that > will be discussed in this working group at IETF-80 needs a draft = posted > since IETF-79, and should have corresponded with = v6ops-chairs@tools.ietf.org > on the topic. >=20 > Our final date to post the working group agenda is 16 March. I will = post a > preliminary agenda on 7 March and repost on 14 March; these will be = for > comment. >=20 > early bird (reduced price) registration cut-off is 18 March. >=20 > . 2011-03-27 - 2011-04-01: 80th IETF Meeting in Prague, Czech > Republic. >=20 > "Be there or be square", as my daughter tells me... > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From d.sturek@att.net Mon Feb 21 11:29:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75BCE3A7162 for ; Mon, 21 Feb 2011 11:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.124 X-Spam-Level: X-Spam-Status: No, score=-0.124 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMDLctAjlmXr for ; Mon, 21 Feb 2011 11:29:39 -0800 (PST) Received: from nm9.bullet.mail.ac4.yahoo.com (nm9.bullet.mail.ac4.yahoo.com [98.139.52.206]) by core3.amsl.com (Postfix) with SMTP id 52C073A714B for ; Mon, 21 Feb 2011 11:29:39 -0800 (PST) Received: from [98.139.52.189] by nm9.bullet.mail.ac4.yahoo.com with NNFMP; 21 Feb 2011 19:30:16 -0000 Received: from [98.139.52.183] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 21 Feb 2011 19:30:16 -0000 Received: from [127.0.0.1] by omp1066.mail.ac4.yahoo.com with NNFMP; 21 Feb 2011 19:30:16 -0000 X-Yahoo-Newman-Id: 633498.86572.bm@omp1066.mail.ac4.yahoo.com Received: (qmail 3122 invoked from network); 21 Feb 2011 19:30:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1298316616; bh=64qmFhR/HMMgRgcXKeUDrowzSO7RLPWaUY/NBBCmaD8=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=RiXM3Yo/7Oas0D0kGBCf5hK7pRTaGUbTyRbLHYpVKyKpcFRvXUEj5g/JVqs3bVkk09dvc8NhTcgAZm+js16ZyCyLqxyrGZp68OCiPWusdjUepckMM8DR6BNe3B+RqZ946ZTpQzm7z0WgpqdS3lH/W0FaqIEjh0bfCniJW4AaLCM= Received: from Studio (d.sturek@174.78.56.227 with login) by smtp102.sbc.mail.ac4.yahoo.com with SMTP; 21 Feb 2011 11:30:13 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: CRM6RDAVM1nRtlGhZ8QiQahrgJ.eMd.g.YJsI3CexE6N1rG LS4fEvIG7Hk_1HK_1mF3R80KMqAcf1SH4nj_PkCQcU2dWuGc6uz2edj32J_4 ucg_Fe3i2ULOSHy3EzjDYVGCZwRd_cl2VLgOzwt8B6MyBUGHUAON0KpaYUPm uilAKXhe1AppMnp3otIKd4rjhV7DV3912JnOrlzbBsRS.2s48EjWXQO3xX4G ZuTEkUU5AwJzN42elKhZuHSAelEDAUrlwQcZ.SYPS_cPtxk50y1_d786R20h jRQMzDHJYNXeYJwF6fw4igytWdAmrlklsefGSgv_6Kdnc0H4lrsM2o1Z4Ewr x9CoVQAUvZAaR0hCfF_Q1fInT.mhKXiS5u8WLmHU- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Fred Baker'" References: <7ED17702-091A-4484-85BF-584C18B8FD6C@cisco.com> <002201cbd1e8$05abe3c0$1103ab40$@sturek@att.net> In-Reply-To: Date: Mon, 21 Feb 2011 11:30:09 -0800 Message-ID: <018501cbd1fd$c198f8b0$44caea10$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvR/U9yZHjC4n51SJ2UyYoMltyxnQAAGPOA Content-Language: en-us Cc: 'IPv6 Operations' , kerlyn2001@gmail.com Subject: Re: [v6ops] Important dates X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 19:29:40 -0000 Yes, we will have two drafts posted by March 7. Don -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Monday, February 21, 2011 11:27 AM To: d.sturek@att.net Cc: 'IPv6 Operations'; kerlyn2001@gmail.com; rdroms@cisco.com; 'Thomas Herbst' Subject: Re: [v6ops] Important dates You'll have a posted internet draft, right? On Feb 21, 2011, at 8:54 AM, Don Sturek wrote: > Hi Fred, > > The Smart Energy 2.0 team on resource discovery (Kerry Lynn, Ralph Droms, > Tom Herbst and myself) would like to request a total of 15 minutes at the > IETF-80 v6ops meeting to discuss a series of I-Ds we will be submitting (and > in some cases refining) for use with SE 2.0. Here are the topics for the > single time block: > 1) ULA address allocation - We plan to use ULAs in our deployment to enable > multicast DNS (m-DNS) resource discovery > 2) ULA prefix delegation/proxy - At IETF-79, we were to work with the > advanced v6ops draft (draft-wbeebee-v6ops-ipv6-cpe-router-bis-04) on this > topic but I think it did not progress due to other pressing issues in that > draft. Unfortunately, this topic will be front and center when the SE 2 > solution deploys next year so we will at least put a big target out that > people can complain about :-) > > Don > > > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Fred Baker > Sent: Friday, February 18, 2011 10:03 PM > To: IPv6 Operations > Subject: [v6ops] Important dates > > http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 > > We have asked for our usual two sessions, 2.5 hours and 2 hours in length. > With any luck neither of them will be on Friday :-) The IETF-80 agenda > should be sorted out by the fourth of March. > > The final date for submission of new (-00) drafts is 7 March. Final date for > updated documents is 14 March. With one exception (a testing report, for > which the proceedings will be the enduring documentation), any draft that > will be discussed in this working group at IETF-80 needs a draft posted > since IETF-79, and should have corresponded with v6ops-chairs@tools.ietf.org > on the topic. > > Our final date to post the working group agenda is 16 March. I will post a > preliminary agenda on 7 March and repost on 14 March; these will be for > comment. > > early bird (reduced price) registration cut-off is 18 March. > > . 2011-03-27 - 2011-04-01: 80th IETF Meeting in Prague, Czech > Republic. > > "Be there or be square", as my daughter tells me... > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From jcurran@istaff.org Mon Feb 21 13:00:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96ED3A6F53 for ; Mon, 21 Feb 2011 13:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7738ocKpCJY for ; Mon, 21 Feb 2011 13:00:01 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 684C53A6FED for ; Mon, 21 Feb 2011 13:00:01 -0800 (PST) Received: from [59.188.192.112] by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1PrcYv-0005Hb-Qf; Mon, 21 Feb 2011 20:40:54 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 59.188.192.112 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18qGeReapdfP21SIERgrnNz Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: John Curran In-Reply-To: <4D62B42E.9020003@dougbarton.us> Date: Tue, 22 Feb 2011 05:00:43 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8D7A4818-D79E-468B-A1AF-38861848C508@istaff.org> References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> <4D61A54F.2090006@bogus.com> <4D62B42E.9020003@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 21:00:06 -0000 On Feb 22, 2011, at 2:51 AM, Doug Barton wrote: > ... > Simply put, if published this draft will do more harm than good. The = major sites are already moving forward on wider v6 deployment, including = Google, the site that popularized whitelisting. (See = http://isoc.org/wp/worldipv6day/, et al) OTOH, sites that genuinely = believe that they need to use this technique are going to use it whether = this document is released or not. "It works for Google" is a much more = persuasive line of reasoning. Releasing this now makes us look like a = bunch of old ladies wagging our fingers at recalcitrant children. Doug -=20 =20 I'm not certain I read the draft the same way (doing more harm=20 than good), as section 9 clearly acknowledges that "major domains=20 may find DNS whitelisting a beneficial temporary tactic in their=20 transition to IPv6. Such temporary use during the transition=20 to IPv6 is broadly accepted within the community, so long as it=20 does not become a long-term practice." While sites that genuinely believe they need to use this technique=20 may have consider many of the implications to them, the costs imparted to others and resulting scaling properties are quite suboptimal. I believe it makes sense to publish a draft which=20 points this out and notes that it is still reasonable due to their temporary nature, or to acknowledge the permanent nature of these whitelists and start working on mechanisms for scalable long-term=20 management of them. /John p.s. (my views alone; 100% recycled electrons used in this message) From brian.e.carpenter@gmail.com Mon Feb 21 13:03:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F463A70F9 for ; Mon, 21 Feb 2011 13:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yHOSrATGB-R for ; Mon, 21 Feb 2011 13:03:43 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 9C7F23A6F53 for ; Mon, 21 Feb 2011 13:03:43 -0800 (PST) Received: by fxm15 with SMTP id 15so2932378fxm.31 for ; Mon, 21 Feb 2011 13:04:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YtfXTiicvvs/+xrir9mwrZwEnmwae7AWcMZ/GFLdOJs=; b=OTC/Vi7lKRaziTImHikN4VcMZY+iwrndA/E8ULDqlOXvq0R1JxUkkXNh0DJ6ofYdX7 dKBzfY5134Ggwr84jLxwFyfLm16G9anT2a1S07zU5mddsgAiGS6YY1HY0YGzraQAy4HI 4b0ZSe/IWDt1CK4A8BGyJkXG23x4CuSr+3OM0= 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=Gw6QSrCKRXZ9/Lz7PxES+/MRG4k/c8Fn4Js5tz+jU4H3YdUouEHbsL1W1S5ue3KZlC lItDLCxFl2SDSo916sfdg/Ijetu6C74y1qxwWRNljQ9p8I13067DKUaFGROwjS443uY4 yPrE0FNrIs8dYPkb6SoNqCC+0xA3Ss3j/u0+A= Received: by 10.223.145.15 with SMTP id b15mr2415074fav.42.1298322265305; Mon, 21 Feb 2011 13:04:25 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id j12sm2688391fax.33.2011.02.21.13.04.21 (version=SSLv3 cipher=OTHER); Mon, 21 Feb 2011 13:04:24 -0800 (PST) Message-ID: <4D62D353.1000507@gmail.com> Date: Tue, 22 Feb 2011 10:04:19 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Doug Barton References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> <4D61A54F.2090006@bogus.com> <4D62B42E.9020003@dougbarton.us> <4D62B699.3040102@bogus.com> <4D62B7A7.1000108@dougbarton.us> In-Reply-To: <4D62B7A7.1000108@dougbarton.us> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 21:03:44 -0000 On 2011-02-22 08:06, Doug Barton wrote: > On 02/21/2011 11:01, Joel Jaeggli wrote: >> On 2/21/11 10:51 AM, Doug Barton wrote: >>> On 02/20/2011 15:35, Joel Jaeggli wrote: >>>> So far on this Last call we've heard from: >>>> >>>> Brian Carpenter >>>> Fred Baker (wg chair) >>>> Joel Jaeggli (wg chair) >>>> Jason Livingood (author) >>>> >>>> Deadline is end of monday everywhere to get your .02 in. >>> >>> With respect to the authors I think this draft is a bad idea, and I >>> oppose it moving forward. >> >> I proposed a series of edits (sent to jason first due to their length) >> that neutralize the tone a bit but without I think altering the content. >> I think that the characterization of the problems with a whitelisting >> approach is useful and important. It's going to (has) happened anyway >> and it's not a "we told you so" it's "these are the issues you have to >> contend with." > > I would be willing to reconsider my position after reviewing a new > draft, but I admit to a strong bias. More to the point, I don't think > that anyone has deployed this solution without thinking through the > implications (certainly not on the larger sites) which is one of the > reasons I think that publishing the draft at all is at best > counterproductive. Not surprisingly, I disagree. To be blunt, the argument "Google's doing it, so it must be right" is pretty powerful. I don't doubt that Google thought it through; I know that they discarded at least one alternative solution. I don't have much faith that other content providers will be so careful. I am reminded of the objections to RFC 2993 being published. Sadly, its warnings were largely ignored: a large part of the mess we are now in. Brian From dougb@dougbarton.us Mon Feb 21 13:09:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48F893A7161 for ; Mon, 21 Feb 2011 13:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGM90US3nuJ7 for ; Mon, 21 Feb 2011 13:09:30 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id D778D3A6F53 for ; Mon, 21 Feb 2011 13:09:29 -0800 (PST) Received: (qmail 21295 invoked by uid 399); 21 Feb 2011 21:10:09 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 21 Feb 2011 21:10:09 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D62D4B0.7060107@dougbarton.us> Date: Mon, 21 Feb 2011 13:10:08 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Curran References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> <4D61A54F.2090006@bogus.com> <4D62B42E.9020003@dougbarton.us> <8D7A4818-D79E-468B-A1AF-38861848C508@istaff.org> In-Reply-To: <8D7A4818-D79E-468B-A1AF-38861848C508@istaff.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 21:09:31 -0000 On 02/21/2011 13:00, John Curran wrote: > On Feb 22, 2011, at 2:51 AM, Doug Barton wrote: >> ... >> Simply put, if published this draft will do more harm than good. The major sites are already moving forward on wider v6 deployment, including Google, the site that popularized whitelisting. (See http://isoc.org/wp/worldipv6day/, et al) OTOH, sites that genuinely believe that they need to use this technique are going to use it whether this document is released or not. "It works for Google" is a much more persuasive line of reasoning. Releasing this now makes us look like a bunch of old ladies wagging our fingers at recalcitrant children. > > Doug - > > I'm not certain I read the draft the same way (doing more harm > than good), as section 9 clearly acknowledges that "major domains > may find DNS whitelisting a beneficial temporary tactic in their > transition to IPv6. Such temporary use during the transition > to IPv6 is broadly accepted within the community, so long as it > does not become a long-term practice." Yes, I read the same thing. AFTER pages and pages of text that basically say, "YOU'RE DOING IT WRONG." I have stated in other fora that we have to stop telling people that are actually deploying IPv6 that they are doing it wrong, both because that's detrimental on its face, and because given the incredibly limited amount of actual experience that we have with IPv6 on a wide-spread basis it's at best arrogant for anyone to say so at this point. The other reason I find the draft objectionable (and I've repeated this once already, so this will be the last time today) is that the people who are deploying this solution don't _need_ us to to tell them it shouldn't be a long-term practice. They already know that, and are already taking steps to move past it. > While sites that genuinely believe they need to use this technique > may have consider many of the implications to them, the costs > imparted to others Can you define what those "costs imparted to others" are? > and resulting scaling properties are quite > suboptimal. I believe it makes sense to publish a draft which > points this out and notes that it is still reasonable due to their > temporary nature, or to acknowledge the permanent nature of these > whitelists and start working on mechanisms for scalable long-term > management of them. I have been following this issue closely and I haven't seen one single statement that anyone believes that this should be a long-term solution, or that anyone plans to make it so. Do you have a reference that I may have missed? So to summarize once more, no good can come from publishing this, and it's likely that it will at least step on toes completely without reason to do so. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From dougb@dougbarton.us Mon Feb 21 13:17:46 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D35AD3A7132 for ; Mon, 21 Feb 2011 13:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFM-w7vJVDCd for ; Mon, 21 Feb 2011 13:17:45 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 7F3123A712A for ; Mon, 21 Feb 2011 13:17:45 -0800 (PST) Received: (qmail 1085 invoked by uid 399); 21 Feb 2011 21:18:24 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 21 Feb 2011 21:18:24 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D62D69E.10303@dougbarton.us> Date: Mon, 21 Feb 2011 13:18:22 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian E Carpenter References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> <4D61A54F.2090006@bogus.com> <4D62B42E.9020003@dougbarton.us> <4D62B699.3040102@bogus.com> <4D62B7A7.1000108@dougbarton.us> <4D62D353.1000507@gmail.com> In-Reply-To: <4D62D353.1000507@gmail.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 21:17:46 -0000 On 02/21/2011 13:04, Brian E Carpenter wrote: > On 2011-02-22 08:06, Doug Barton wrote: >> On 02/21/2011 11:01, Joel Jaeggli wrote: >>> On 2/21/11 10:51 AM, Doug Barton wrote: >>>> On 02/20/2011 15:35, Joel Jaeggli wrote: >>>>> So far on this Last call we've heard from: >>>>> >>>>> Brian Carpenter >>>>> Fred Baker (wg chair) >>>>> Joel Jaeggli (wg chair) >>>>> Jason Livingood (author) >>>>> >>>>> Deadline is end of monday everywhere to get your .02 in. >>>> >>>> With respect to the authors I think this draft is a bad idea, and I >>>> oppose it moving forward. >>> >>> I proposed a series of edits (sent to jason first due to their length) >>> that neutralize the tone a bit but without I think altering the content. >>> I think that the characterization of the problems with a whitelisting >>> approach is useful and important. It's going to (has) happened anyway >>> and it's not a "we told you so" it's "these are the issues you have to >>> contend with." >> >> I would be willing to reconsider my position after reviewing a new >> draft, but I admit to a strong bias. More to the point, I don't think >> that anyone has deployed this solution without thinking through the >> implications (certainly not on the larger sites) which is one of the >> reasons I think that publishing the draft at all is at best >> counterproductive. > > Not surprisingly, I disagree. To be blunt, the argument > "Google's doing it, so it must be right" is pretty powerful. > I don't doubt that Google thought it through; I know that they > discarded at least one alternative solution. I don't have much > faith that other content providers will be so careful. > > I am reminded of the objections to RFC 2993 being published. > Sadly, its warnings were largely ignored: a large part of the > mess we are now in. Actually I agree that the situations are incredibly similar. IETF theorists ignoring operational reality on ships that have already sailed. Imagine what a better place the world would be if the IETF had embraced the fact that people liked/needed NAT and had worked on finding a more robust way to do it instead of shouting at people that they should not want/use it. Sorry for the strong words, and I hope you(pl.) understand that no personal attack is intended. But it gets really frustrating to see the same silly stuff year after year after year because certain people in the IETF are so determined to have architectural purity that they ignore the operational necessities of the people who actually need to make the stuff work. Doug ( ... and no, it doesn't matter if you disagree with their definition of "works" either.) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From jason_livingood@cable.comcast.com Mon Feb 21 13:29:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843F33A7151 for ; Mon, 21 Feb 2011 13:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=2.313, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LgNueQ2B2GA for ; Mon, 21 Feb 2011 13:29:30 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id BD4463A717B for ; Mon, 21 Feb 2011 13:29:29 -0800 (PST) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.114402388; Mon, 21 Feb 2011 16:30:06 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Mon, 21 Feb 2011 16:30:06 -0500 From: "Livingood, Jason" To: Doug Barton , Brian E Carpenter Thread-Topic: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 Thread-Index: AQHL0g6BHlD8aRXUM0qpd4CKFAnNyQ== Date: Mon, 21 Feb 2011 21:30:05 +0000 Message-ID: In-Reply-To: <4D62D69E.10303@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.227.141] Content-Type: multipart/alternative; boundary="_000_C98842C419A67jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 21:29:33 -0000 --_000_C98842C419A67jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for the strong words, and I hope you(pl.) understand that no personal attack is intended. But it gets really frustrating to see the same silly stuff year after year after year because certain people in the IETF are so determined to have architectural purity that they ignore the operational necessities of the people who actually need to make the stuff work. Doug - I'm glad you speak in support of those (like me, the humble author) = who are focused on real operational issues involved in the deployment of IP= v6. ;-) It is the primary reason why the document was written. To wit, pla= yed forward a few years and widely adopted, DNS whitelisting could well be = operationally problematic. As the draft attempts to make clear, the short-t= erm is an entirely different matter. Regards Jason --_000_C98842C419A67jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1746F219BEDE924FBDE409FA9ACC89D6@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Sorry for the strong words, and I hope you(pl.) understand that no
personal attack is intended. But it gets really frustrating to see the=
same silly stuff year after year after year because certain people in =
the IETF are so determined to have architectural purity that they igno= re
the operational necessities of the people who actually need to make th= e
stuff work.

Doug - I'm glad you speak in support of those (like me, the humble aut= hor) who are focused on real operational issues involved in the deployment = of IPv6. ;-)  It is the primary reason why the document was written. T= o wit, played forward a few years and widely adopted, DNS whitelisting could well be operationally problematic. = As the draft attempts to make clear, the short-term is an entirely differen= t matter.

Regards

Jason
--_000_C98842C419A67jasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Mon Feb 21 13:49:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D19C83A7157 for ; Mon, 21 Feb 2011 13:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.665 X-Spam-Level: X-Spam-Status: No, score=-105.665 tagged_above=-999 required=5 tests=[AWL=1.557, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KamZ59-f2bxg for ; Mon, 21 Feb 2011 13:49:12 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 391A63A6FEA for ; Mon, 21 Feb 2011 13:49:12 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.114404632; Mon, 21 Feb 2011 16:49:50 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Mon, 21 Feb 2011 16:49:47 -0500 From: "Livingood, Jason" To: Doug Barton , John Curran Thread-Topic: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 Thread-Index: AQHL0hFBjJt6oOYqe0eKEa/r9sLU9A== Date: Mon, 21 Feb 2011 21:49:47 +0000 Message-ID: In-Reply-To: <4D62D4B0.7060107@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.227.141] Content-Type: multipart/alternative; boundary="_000_C98844BE19A7Bjasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 21:49:13 -0000 --_000_C98844BE19A7Bjasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I read the same thing. AFTER pages and pages of text that basically say, "YOU'RE DOING IT WRONG." [JL] I'm happy to take suggestions on text you think is too strong. I have stated in other fora that we have to stop telling people that are actually deploying IPv6 that they are doing it wrong, both because that's detrimental on its face, and because given the incredibly limited amount of actual experience that we have with IPv6 on a wide-spread basis it's at best arrogant for anyone to say so at this point. [JL] The document points out the many implications of whitelisting. It also= describes how it can make sense for some domains in the short term but tha= t it is problematic in the long-term (which you seem to agree with). The do= cument was not written based on theory but was instead motivated by some ac= tual experience. If you believe any of the implications listed in the docum= ent are without merit or wish to suggest modifications to them (or other sp= ecific parts of the document), I'm all ears and I've been responsive to eve= ry single change requested (including from folks doing whitelisting). Can you define what those "costs imparted to others" are? [JL] To give one perspective, that of a network operator, please see Sectio= n 7.3.1, 7.3.3, 7.3.4, and 7.3.6. A network operator needs to add staff to = discover which domains whitelist, discover the policies and application pro= cess for each domain, apply to be whitelisted for each domain, and monitor = progress / approvals / appeals. Then, once it is place, monitoring must be = put in place to ensure whitelisting remains in place and there is manual in= tervention via NOC and IPv6 SMEs when de-whitelisting occurs (through error= or for some other reason). In addition, let's not leave off the added comp= lexity of troubleshooting end user problems (we measure this in incremental= seconds/minutes on the phone with users). I have been following this issue closely and I haven't seen one single statement that anyone believes that this should be a long-term solution, or that anyone plans to make it so. Do you have a reference that I may have missed? So to summarize once more, no good can come from publishing this, and it's likely that it will at least step on toes completely without reason to do so. [JL] That didn't seem to be the sentiment at the WG meeting in Beijing, nor= on the list up to the point of your email. If in fact no one believes this= should be a long-term tactic, then what is the downside of the document if= it attempts to detail all the reasons why this is so? Jason --_000_C98844BE19A7Bjasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Yes, I read the same thing. AFTER pages and pages of text that basical= ly
say, "YOU'RE DOING IT WRONG."

[JL] I'm happy to take suggestions on text you think is too strong.

I have stated in other fora that we have
to stop telling people that are actually deploying IPv6 that they are =
doing it wrong, both because that's detrimental on its face, and becau= se
given the incredibly limited amount of actual experience that we have =
with IPv6 on a wide-spread basis it's at best arrogant for anyone to s= ay
so at this point.

[JL] The document points out the many implications of whitelisting. It= also describes how it can make sense for some domains in the short term bu= t that it is problematic in the long-term (which you seem to agree with). T= he document was not written based on theory but was instead motivated by some actual experience. If you beli= eve any of the implications listed in the document are without merit or wis= h to suggest modifications to them (or other specific parts of the document= ), I'm all ears and I've been responsive to every single change requested (including from folks doing whitelisting)= . 

Can you define what those "costs imparted to others" are?

[JL] To give one perspective, that of a network operator, please see S= ection 7.3.1, 7.3.3, 7.3.4, and 7.3.6. A network operator needs to add staf= f to discover which domains whitelist, discover the policies and applicatio= n process for each domain, apply to be whitelisted for each domain, and monitor progress / approvals / appe= als. Then, once it is place, monitoring must be put in place to ensure whit= elisting remains in place and there is manual intervention via NOC and IPv6= SMEs when de-whitelisting occurs (through error or for some other reason). In addition, let's not leave off= the added complexity of troubleshooting end user problems (we measure this= in incremental seconds/minutes on the phone with users).  

I have been following this issue closely and I haven't seen one single=
statement that anyone believes that this should be a long-term solutio= n,
or that anyone plans to make it so. Do you have a reference that I may=
have missed?

So to summarize once more, no good can come from publishing this, and =
it's likely that it will at least step on toes completely without reas= on
to do so.

[JL] That didn't seem to be the sentiment at the WG meeting in Beijing= , nor on the list up to the point of your email. If in fact no one believes= this should be a long-term tactic, then what is the downside of the docume= nt if it attempts to detail all the reasons why this is so?

Jason
--_000_C98844BE19A7Bjasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Mon Feb 21 13:56:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6FFC3A711E for ; Mon, 21 Feb 2011 13:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.372 X-Spam-Level: X-Spam-Status: No, score=-106.372 tagged_above=-999 required=5 tests=[AWL=2.090, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkj2eVAzfT9K for ; Mon, 21 Feb 2011 13:56:40 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id BA3323A6FEA for ; Mon, 21 Feb 2011 13:56:39 -0800 (PST) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.114405461; Mon, 21 Feb 2011 16:57:15 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Mon, 21 Feb 2011 16:57:15 -0500 From: "Livingood, Jason" To: Joel Jaeggli , Doug Barton Thread-Topic: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 Thread-Index: AQHL0hJMiSnmnTOq9kOktdj8dZOxyw== Date: Mon, 21 Feb 2011 21:57:14 +0000 Message-ID: In-Reply-To: <4D62B699.3040102@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.227.141] Content-Type: multipart/alternative; boundary="_000_C988498919AAEjasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 21:56:40 -0000 --_000_C988498919AAEjasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I proposed a series of edits (sent to jason first due to their length) that neutralize the tone a bit but without I think altering the content. I think that the characterization of the problems with a whitelisting approach is useful and important. It's going to (has) happened anyway and it's not a "we told you so" it's "these are the issues you have to contend with." [JL] I am mid-way through those edits (will take another day or so to facto= r them all in). These suggestions will be adopted in a =9603 version along = with the other specific feedback received in the past few days of WGLC. Regards Jason --_000_C988498919AAEjasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <81F22BEB063A984C84817FDEB4266545@cable.comcast.com> Content-Transfer-Encoding: quoted-printable

I proposed a series of edits (sent to jason first due to their length)
that neutralize the tone a bit but without I think altering the conten= t.
I think that the characterization of the problems with a whitelisting<= /div>
approach is useful and important. It's going to (has) happened anyway<= /div>
and it's not a "we told you so" it's "these are the iss= ues you have to
contend with."

[JL] I am mid-way through those edits (will take another day or so to = factor them all in). These suggestions will be adopted in a =9603 version a= long with the other specific feedback received in the past few days of WGLC= .

Regards
Jason
--_000_C988498919AAEjasonlivingoodcablecomcastcom_-- From dougb@dougbarton.us Mon Feb 21 13:59:14 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B073A713E for ; Mon, 21 Feb 2011 13:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGIm+wYA7lPG for ; Mon, 21 Feb 2011 13:59:13 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 58B8F3A711E for ; Mon, 21 Feb 2011 13:59:12 -0800 (PST) Received: (qmail 1745 invoked by uid 399); 21 Feb 2011 21:59:50 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 21 Feb 2011 21:59:50 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D62E055.4050408@dougbarton.us> Date: Mon, 21 Feb 2011 13:59:49 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Livingood, Jason" References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 21:59:14 -0000 On 02/21/2011 13:49, Livingood, Jason wrote: > Yes, I read the same thing. AFTER pages and pages of text that basically > say, "YOU'RE DOING IT WRONG." > > > [JL] I'm happy to take suggestions on text you think is too strong. That would be operating from the premise that there is any way to say these things that are useful, or at best not offensive. I disagree with that premise. :) > Can you define what those "costs imparted to others" are? > > > [JL] To give one perspective, that of a network operator, please see > Section 7.3.1, 7.3.3, 7.3.4, and 7.3.6. A network operator needs to add > staff to discover which domains whitelist, discover the policies and > application process for each domain, apply to be whitelisted for each > domain, and monitor progress / approvals / appeals. Then, once it is > place, monitoring must be put in place to ensure whitelisting remains in > place and there is manual intervention via NOC and IPv6 SMEs when > de-whitelisting occurs (through error or for some other reason). In > addition, let's not leave off the added complexity of troubleshooting > end user problems (we measure this in incremental seconds/minutes on the > phone with users). Ok, I'll grant you all of those, but I will also point out that all of those costs are voluntary. You don't have to choose to do any of those things. I think it's admirable if you do, since more traffic over IPv6 is a great thing. However I return to my main premise which is: 1. 99.9% of the organizations who have chose this solution already understand these issues, and 2. The 0.1% who don't, don't care. Therefore no good can come from publishing this. > I have been following this issue closely and I haven't seen one single > statement that anyone believes that this should be a long-term > solution, > or that anyone plans to make it so. Do you have a reference that I may > have missed? > > So to summarize once more, no good can come from publishing this, and > it's likely that it will at least step on toes completely without > reason to do so. > > > [JL] That didn't seem to be the sentiment at the WG meeting in Beijing, > nor on the list up to the point of your email. ... and please accept my apologies for not having been able to speak up sooner. > If in fact no one > believes this should be a long-term tactic, then what is the downside of > the document if it attempts to detail all the reasons why this is so? I've already explained the downside several times. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From tena@huawei.com Mon Feb 21 14:13:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9267C3A715B for ; Mon, 21 Feb 2011 14:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.361 X-Spam-Level: X-Spam-Status: No, score=-106.361 tagged_above=-999 required=5 tests=[AWL=0.236, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjUbIKYgtZ2b for ; Mon, 21 Feb 2011 14:13:16 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 633A43A714D for ; Mon, 21 Feb 2011 14:13:16 -0800 (PST) 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 <0LGZ00G2LN39PE@usaga02-in.huawei.com> for v6ops@ietf.org; Mon, 21 Feb 2011 14:13:57 -0800 (PST) Received: from TingZousc1 ([10.193.34.106]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGZ0063RN37LO@usaga02-in.huawei.com> for v6ops@ietf.org; Mon, 21 Feb 2011 14:13:57 -0800 (PST) Date: Mon, 21 Feb 2011 14:13:55 -0800 From: Tina Tsou In-reply-to: To: "'Livingood, Jason'" , 'Joel Jaeggli' , 'Doug Barton' Message-id: <026f01cbd214$a1b71420$e5253c60$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vYaE7yudjUAct/swN41qBg)" Content-language: en-us Thread-index: AQHL0hJMiSnmnTOq9kOktdj8dZOxy5QMg5dQ References: <4D62B699.3040102@bogus.com> Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 22:13:24 -0000 This is a multi-part message in MIME format. --Boundary_(ID_vYaE7yudjUAct/swN41qBg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I generally support this document as attempt on real operational issues involved in the deployment of IPv6. Comments on section 10.1 "DNSSEC Considerations" are below. It says that different answers are sent to different querying hosts. If those are all known in advance, and the server has the DNS zone signing key, it can separately sign the various alternative answer data sets however you want. If they are not known in advance, then you have to have the keys on-line so you can sign answer data in real time. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Livingood, Jason Sent: Monday, February 21, 2011 1:57 PM To: Joel Jaeggli; Doug Barton Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 I proposed a series of edits (sent to jason first due to their length) that neutralize the tone a bit but without I think altering the content. I think that the characterization of the problems with a whitelisting approach is useful and important. It's going to (has) happened anyway and it's not a "we told you so" it's "these are the issues you have to contend with." [JL] I am mid-way through those edits (will take another day or so to factor them all in). These suggestions will be adopted in a -03 version along with the other specific feedback received in the past few days of WGLC. Regards Jason --Boundary_(ID_vYaE7yudjUAct/swN41qBg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

I generally support this = document as attempt on real operational issues involved in the = deployment of IPv6.

 

Comments on section 10.1 = “DNSSEC Considerations” are below.

It says that different answers = are sent to different querying hosts. If those are all known in advance, = and the server has the DNS zone signing key, it can separately sign the = various alternative answer data sets however you want. If they are not = known in advance, then you have to have the keys on-line so you can sign = answer data in real time…

 

 

We keep our = promises with one another – no matter = what!

 

Best = Regards,

Tina = TSOU

http://tinatsou.weebly.com/contact= .html

 

From: v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of Livingood, = Jason
Sent: Monday, February 21, 2011 1:57 PM
To: = Joel Jaeggli; Doug Barton
Cc: IPv6 Ops WG
Subject: = Re: [v6ops] WGLC = draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02

 


I proposed a series of edits (sent to = jason first due to their length)

that neutralize the tone a bit but without I = think altering the content.

I think that the characterization of the = problems with a whitelisting

approach is useful and important. It's going = to (has) happened anyway

and it's not a "we told you so" it's = "these are the issues you have = to

contend = with."

 

[JL] I am mid-way through those edits (will = take another day or so to factor them all in). These suggestions will be = adopted in a –03 version along with the other specific feedback = received in the past few days of = WGLC.

 

Regards

Jason

= --Boundary_(ID_vYaE7yudjUAct/swN41qBg)-- From narten@us.ibm.com Mon Feb 21 14:47:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37ED73A70F9 for ; Mon, 21 Feb 2011 14:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVYB33-HWxHs for ; Mon, 21 Feb 2011 14:47:42 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id 2078C3A6F12 for ; Mon, 21 Feb 2011 14:47:42 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1LLw1gZ010471 for ; Mon, 21 Feb 2011 14:58:01 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1LM38CW073448 for ; Mon, 21 Feb 2011 15:03:08 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p1LM0ieN026018 for ; Mon, 21 Feb 2011 15:00:44 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-217-194.mts.ibm.com [9.65.217.194]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p1LM0hcb025868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Feb 2011 15:00:44 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p1LM35o6015377; Mon, 21 Feb 2011 17:03:05 -0500 Message-Id: <201102212203.p1LM35o6015377@cichlid.raleigh.ibm.com> To: Joel Jaeggli In-reply-to: <4D61A54F.2090006@bogus.com> References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> <4D61A54F.2090006@bogus.com> Comments: In-reply-to Joel Jaeggli message dated "Sun, 20 Feb 2011 15:35:43 -0800." Date: Mon, 21 Feb 2011 17:03:05 -0500 From: Thomas Narten Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 22:47:43 -0000 OK. I did a quick read through of the document and think it's mostly fine. Two questions/issues. First, I must have missed the text pointing out that whitelisting is only a heuristic, in that it assumes that the address of query identifies that actual requestor of the DNS info who will ultimately initiate the v6 communication. In fact, the actual network address of the client making the query may be unrelated to the DNS recursive resolvers address, and thus the whitelisting policy a the server may get this wrong. (This is certainly one of the complaints people have raised.) Where is this covered? I assume it is, and I admit to having missed it, so I wonder if the point is being made a little too subtly. :-) Second, is the DNSSEC section really this simple? > 10.1. DNSSEC Considerations > > DNS security extensions defined in [RFC4033], [RFC4034], and > [RFC4035] use cryptographic digital signatures to provide origin > authentication and integrity assurance for DNS data. This is done by > creating signatures for DNS data on a Security-Aware Authoritative > Name Server that can be used by Security-Aware Resolvers to verify > the answers. Since DNS whitelisting is implemented on an > authoritative server, which provides different answers depending upon > which resolver server has sent a query, the DNSSEC chain of trust is > not altered. Therefore there are no DNSSEC implications per se. > However, any implementer of DNS whitelisting should be quite careful > if they implement both DNSSEC signing of their domain and also DNS > whitelisting of that same domain. Specifically, those domains should > ensure that records are being appropriately and reliably signed, > which may well prove operationally and/or technically challenging. This basically says you can make this work just fine with DNSSEC. Is that so? Has this feature been implemented/deployed? I.e., do we have real experience with this? Do DNSSEC folk agree with the above text? Thomas From suresh.krishnan@ericsson.com Mon Feb 21 14:50:18 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D433A7071 for ; Mon, 21 Feb 2011 14:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.942 X-Spam-Level: X-Spam-Status: No, score=-101.942 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZvTa1-w-Lgp for ; Mon, 21 Feb 2011 14:50:17 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id C3A6C3A6F12 for ; Mon, 21 Feb 2011 14:50:17 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p1LNbZWm005080; Mon, 21 Feb 2011 17:37:42 -0600 Received: from [142.133.10.107] (147.117.20.213) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.2.234.1; Mon, 21 Feb 2011 17:50:47 -0500 Message-ID: <4D62EC35.9060500@ericsson.com> Date: Mon, 21 Feb 2011 17:50:29 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IPv6 Ops WG , "Livingood, Jason" References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> In-Reply-To: <4D5814F9.3070800@bogus.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] WGLC Review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 22:50:19 -0000 Hi Jason, Thanks for putting together this draft. It provides a very good overview of the whitelisting process. I did have a few comments though * Meta comment ============== * This draft does not mention using a different (sub-)domain name as an alternative to whitelisting (e.g. as done in http://ipv6.google.com/ or http://www.v6.facebook.com/). I am not sure if you wanted to cover this here, but as the draft intends to also cover "what alternatives may exist", I think it may be useful to do so. * Major ======= * Section 2 (Figures 1 and 2) I think the system logic (Fig 1) and the associated diagram (Fig 2) being described here are not correct. They ignore the fact that the DNS query is for a specific type (A or AAAA but not both) and the draft needs to mainly describe what happens when a AAAA query is received. I think it would greatly simplify things if these two were redone. e.g. Here is what I think the system logic should be 1: The authoritative DNS server for example.com receives a DNS AAA query for www.example.com, for which AAAA (IPv6) address records exist. 2: The authoritative DNS server examines the IP address of the DNS recursive resolver sending the query. 3: The authoritative DNS server checks this IP address against the access control list (ACL) that is the DNS whitelist. 4: If the DNS recursive resolver's IP address IS listed in the ACL, then the response to that specific DNS recursive resolver can contain AAAA (IPv6) address records. 5: If the DNS recursive resolver's IP address IS NOT listed in the ACL, then the response to that specific DNS recursive resolver can cannot contain AAAA (IPv6) address records. The server should return a response with the response code (RCODE) being set to 0 (No Error) with an empty answer section. * Editorial =========== * The reference names are too long and they obstruct the flow of the document. e.g. "Network World Article on IETF 77 DNSOP WG Presentation" Is it possible to shorten them? * Section 11 s/advise the end use/advise the end user/ Cheers Suresh On 11-02-13 12:29 PM, Joel Jaeggli wrote: > The halfway point has been reached, please get your feedback in by > monday the 21st... > > > On 2/6/11 7:35 PM, Joel Jaeggli wrote: >> This announcement is to serve as the beginning of the WGLC for: >> >> draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 >> >> http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 >> >> WGLC runs from Monday Feb 7th to Monday Feb 21st. >> >> The 01 version of this document received a lot of good feedback on this >> list which has been incorporated into this version of the draft. >> >> joelja >> _______________________________________________ >> 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 ek@google.com Mon Feb 21 18:34:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83603A67F1 for ; Mon, 21 Feb 2011 18:34:56 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaWPTPBIoXhK for ; Mon, 21 Feb 2011 18:34:55 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id A201D3A67F0 for ; Mon, 21 Feb 2011 18:34:54 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p1M2ZafN028718 for ; Mon, 21 Feb 2011 18:35:36 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298342137; bh=KEU9B7FvDJ6k2FVF91kPnesMHMk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=XSbqcLQf2+zHybsqSfGL4OxzM7na4gSJi+LDVZtz8Ev2H8Te0uf+8g+wCjbKuOheL m+XjxL5CXcbn2fIud6Vaw== Received: from qyk10 (qyk10.prod.google.com [10.241.83.138]) by wpaz13.hot.corp.google.com with ESMTP id p1M2ZZoi014113 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 21 Feb 2011 18:35:35 -0800 Received: by qyk10 with SMTP id 10so1843016qyk.11 for ; Mon, 21 Feb 2011 18:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bOiWYhPtUKJCawUBBU5w0OTCKJWp78UcMJovHfbv11Q=; b=eLUxyFFe5yPmKZ2ornfME+2QB/inWifEO6ywuDJT7N4tFvqZySNKZYrgqI8gMbo0J9 K9QM7x9Iga+EdSSm3lDA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sFDKUF7G9/acesmst3QXvwfZJbM9eWEX+65qF6Jo4p9Oe4L2gq1tJYa5Iu97zYS6Gc D0XrHKjkD6QUDN1fiUQQ== MIME-Version: 1.0 Received: by 10.229.214.10 with SMTP id gy10mr1577457qcb.130.1298342134923; Mon, 21 Feb 2011 18:35:34 -0800 (PST) Received: by 10.229.121.8 with HTTP; Mon, 21 Feb 2011 18:35:34 -0800 (PST) In-Reply-To: <201102212203.p1LM35o6015377@cichlid.raleigh.ibm.com> References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> <4D61A54F.2090006@bogus.com> <201102212203.p1LM35o6015377@cichlid.raleigh.ibm.com> Date: Tue, 22 Feb 2011 11:35:34 +0900 Message-ID: From: Erik Kline To: Thomas Narten Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 02:34:56 -0000 > Second, is the DNSSEC section really this simple? > >> =C2=A0 =C2=A010.1. =C2=A0DNSSEC Considerations >> >> =C2=A0 =C2=A0DNS security extensions defined in [RFC4033], [RFC4034], an= d >> =C2=A0 =C2=A0[RFC4035] use cryptographic digital signatures to provide o= rigin >> =C2=A0 =C2=A0authentication and integrity assurance for DNS data. =C2=A0= This is done by >> =C2=A0 =C2=A0creating signatures for DNS data on a Security-Aware Author= itative >> =C2=A0 =C2=A0Name Server that can be used by Security-Aware Resolvers to= verify >> =C2=A0 =C2=A0the answers. =C2=A0Since DNS whitelisting is implemented on= an >> =C2=A0 =C2=A0authoritative server, which provides different answers depe= nding upon >> =C2=A0 =C2=A0which resolver server has sent a query, the DNSSEC chain of= trust is >> =C2=A0 =C2=A0not altered. =C2=A0Therefore there are no DNSSEC implicatio= ns per se. >> =C2=A0 =C2=A0However, any implementer of DNS whitelisting should be quit= e careful >> =C2=A0 =C2=A0if they implement both DNSSEC signing of their domain and a= lso DNS >> =C2=A0 =C2=A0whitelisting of that same domain. =C2=A0Specifically, those= domains should >> =C2=A0 =C2=A0ensure that records are being appropriately and reliably si= gned, >> =C2=A0 =C2=A0which may well prove operationally and/or technically chall= enging. > > This basically says you can make this work just fine with DNSSEC. Is > that so? Has this feature been implemented/deployed? I.e., do we have > real experience with this? Do DNSSEC folk agree with the above text? Certainly we (Google) have not tried to support both whitelisting and DNSSEC. Maybe there is some operational experience with it, but I've not heard of any. From ek@google.com Mon Feb 21 18:47:07 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C57A3A67F6 for ; Mon, 21 Feb 2011 18:47:07 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to-CR9WXNhS2 for ; Mon, 21 Feb 2011 18:47:06 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 3A2103A67EC for ; Mon, 21 Feb 2011 18:47:06 -0800 (PST) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p1M2lmmw009151 for ; Mon, 21 Feb 2011 18:47:48 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298342868; bh=hvDJzPn9IfMXbCCI2CR5hjwkCBM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=DftnZKDtfgdH8kjoRX7/++jIrN+BOE41QMhAd30ZdtxHeEfWD+gqcALqLFyPKp84B tBtZno+u/3BB7lAvfsHew== Received: from qwd6 (qwd6.prod.google.com [10.241.193.198]) by wpaz37.hot.corp.google.com with ESMTP id p1M2lk0J011982 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 21 Feb 2011 18:47:47 -0800 Received: by qwd6 with SMTP id 6so1552676qwd.21 for ; Mon, 21 Feb 2011 18:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HEp9mwPdAeKNn+Fzyk3KRaDoK1Y7pSCQfpiB9K+sxY0=; b=FPKBuZOMm9VFRhHJpySV61VCQj1S87n6PP69aCpEkpbiFYWL25cwot17UbfbDrip4F 1PN1pfeQSKnkyAOkEytA== 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=D+3wEusownJhsv1MH8iy9JPeqSdLFcT9UCOfDbmPn14whijmseSad8Zh6ciS38zKwV avB4QkdrV1SvdOiaYwhA== MIME-Version: 1.0 Received: by 10.229.186.212 with SMTP id ct20mr1584583qcb.92.1298342864903; Mon, 21 Feb 2011 18:47:44 -0800 (PST) Received: by 10.229.121.8 with HTTP; Mon, 21 Feb 2011 18:47:44 -0800 (PST) In-Reply-To: <4D62B42E.9020003@dougbarton.us> References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> <4D61A54F.2090006@bogus.com> <4D62B42E.9020003@dougbarton.us> Date: Tue, 22 Feb 2011 11:47:44 +0900 Message-ID: From: Erik Kline To: Doug Barton Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 02:47:07 -0000 (agreeing with many sentiments) > Simply put, if published this draft will do more harm than good. The major > sites are already moving forward on wider v6 deployment, including Google, > the site that popularized whitelisting. (See > http://isoc.org/wp/worldipv6day/, et al) OTOH, sites that genuinely believe > that they need to use this technique are going to use it whether this > document is released or not. "It works for Google" is a much more persuasive > line of reasoning. Releasing this now makes us look like a bunch of old > ladies wagging our fingers at recalcitrant children. After going 'round and 'round on this deciding if I should care about this document or not, I ultimately decided "not, not at all". The "manual overhead" complaints are certainly real and well understood at this moment. However, we (Google) have publicly stated that all this will be automated and no communication will be required. Note also that Akamai has publicly declared that they will dynamically, automatically decide when to serve AAAAs and when not to. This is indistinguishble from automated whitelisting. I suspect, therefore, this draft will hold no water with them either, but obviously can't speak for them. In the end, I settled on the opinion that the IETF probably has to publish RFCs that state warnings about things like "geographic load balancing via DNS has the following implications:...", and then everyone who has to go out and do that anyway goes out and does that anyway. In my mind this document is basically in that category. From jason_livingood@cable.comcast.com Tue Feb 22 06:57:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13593A68E7 for ; Tue, 22 Feb 2011 06:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.118 X-Spam-Level: X-Spam-Status: No, score=-103.118 tagged_above=-999 required=5 tests=[AWL=-1.384, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCOSrVtA7XHB for ; Tue, 22 Feb 2011 06:57:00 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id ADD1E3A689A for ; Tue, 22 Feb 2011 06:57:00 -0800 (PST) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.26857644; Tue, 22 Feb 2011 08:09:16 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Tue, 22 Feb 2011 09:57:37 -0500 From: "Livingood, Jason" To: Doug Barton Thread-Topic: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 Thread-Index: AQHL0hFBjJt6oOYqe0eKEa/r9sLU9JQM1QCAgADIkAA= Date: Tue, 22 Feb 2011 14:57:36 +0000 Message-ID: In-Reply-To: <4D62E055.4050408@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.11] Content-Type: multipart/alternative; boundary="_000_C989382419B96jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 14:57:01 -0000 --_000_C989382419B96jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [JL] To give one perspective, that of a network operator, please see Section 7.3.1, 7.3.3, 7.3.4, and 7.3.6. A network operator needs to add staff to discover which domains whitelist, discover the policies and application process for each domain, apply to be whitelisted for each domain, and monitor progress / approvals / appeals. Then, once it is place, monitoring must be put in place to ensure whitelisting remains in place and there is manual intervention via NOC and IPv6 SMEs when de-whitelisting occurs (through error or for some other reason). In addition, let's not leave off the added complexity of troubleshooting end user problems (we measure this in incremental seconds/minutes on the phone with users). Ok, I'll grant you all of those, but I will also point out that all of those costs are voluntary. [JL] They are optional for the domain doing the whitelisting, but not reall= y for others (such as network operators). Sure, in theory it is optional, b= ut it will not long satisfy some users that they cannot access content X or= Y via IPv6. So the cost burden is voluntary for the whitelisted domain and= involuntary for others IMHO. However I return to my main premise which is: 1. 99.9% of the organizations who have chose this solution already understand these issues, and 2. The 0.1% who don't, don't care. [JL] Others will follow the examples set during the transition. It's import= ant to document this IMHO. I know you disagree, and I appreciate you sharin= g your perspective. Jason --_000_C989382419B96jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3AAF0BE806B23645A5639940C58823F2@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
[JL] To give one perspective, that of a network operator, please see
Section 7.3.1, 7.3.3, 7.3.4, and 7.3.6. A network operator needs to ad= d
staff to discover which domains whitelist, discover the policies and
application process for each domain, apply to be whitelisted for each<= /div>
domain, and monitor progress / approvals / appeals. Then, once it is
place, monitoring must be put in place to ensure whitelisting remains = in
place and there is manual intervention via NOC and IPv6 SMEs when
de-whitelisting occurs (through error or for some other reason). In
addition, let's not leave off the added complexity of troubleshooting<= /div>
end user problems (we measure this in incremental seconds/minutes on t= he
phone with users).

Ok, I'll grant you all of those, but I will also point out that all of=
those costs are voluntary. 

[JL] They are optional for the domain doing the whitelisting, but not = really for others (such as network operators). Sure, in theory it is option= al, but it will not long satisfy some users that they cannot access content= X or Y via IPv6. So the cost burden is voluntary for the whitelisted domain and involuntary for others IMHO. &= nbsp;

However I return to my main premise which is:
1. 99.9% of the organizations who have chose this solution already
understand these issues, and
2. The 0.1% who don't, don't care.

[JL] Others will follow the examples set during the transition. It's i= mportant to document this IMHO. I know you disagree, and I appreciate you s= haring your perspective.

Jason
--_000_C989382419B96jasonlivingoodcablecomcastcom_-- From jcurran@istaff.org Tue Feb 22 08:33:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72EB03A6919 for ; Tue, 22 Feb 2011 08:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5kb4q6N8cs0 for ; Tue, 22 Feb 2011 08:33:27 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 8E7C43A68E6 for ; Tue, 22 Feb 2011 08:33:27 -0800 (PST) Received: from [59.188.192.112] by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1PrusZ-000Cm0-UO; Tue, 22 Feb 2011 16:14:24 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 59.188.192.112 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/qOEfRHWJ7tBdJ2mw2NxTg Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: John Curran In-Reply-To: <4D62D4B0.7060107@dougbarton.us> Date: Wed, 23 Feb 2011 00:34:13 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9809164F-B54C-4865-9134-DC527FA1B982@istaff.org> References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> <4D61A54F.2090006@bogus.com> <4D62B42E.9020003@dougbarton.us> <8D7A4818-D79E-468B-A1AF-38861848C508@istaff.org> <4D62D4B0.7060107@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 16:33:28 -0000 On Feb 22, 2011, at 5:10 AM, Doug Barton wrote: >=20 > I have been following this issue closely and I haven't seen one single = statement that anyone believes that this should be a long-term solution, = or that anyone plans to make it so. Do you have a reference that I may = have missed? Documenting the approach, including its benefits and=20 limitations, is simply the right thing to do. It allows others who come later to gain insight into some of the=20 consideration that went into this particular solution. > So to summarize once more, no good can come from publishing this, and = it's likely that it will at least step on toes completely without reason = to do so. The publication itself is deemed useful by some of the WG. We have yet to hear from a whitelisting party that actually views=20 this as "stepping on toes" by publication (e.g. Erik Kline noted=20 ambivalence & that "IETF probably has to publish RFCs that state=20 warnings about things ...") If some network would be offended by=20 having this technique written up, it's time for them actually say=20 that on this list, less we hold publication up for nothing more=20 than a chimera. /John From fred@cisco.com Tue Feb 22 08:35:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CE573A690F for ; Tue, 22 Feb 2011 08:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.505 X-Spam-Level: X-Spam-Status: No, score=-110.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xXs1P7Vw11G for ; Tue, 22 Feb 2011 08:35:23 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 848023A68E6 for ; Tue, 22 Feb 2011 08:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=503; q=dns/txt; s=iport; t=1298392568; x=1299602168; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=CxA53N/vR/ja+JpOH1PQo4+iui4VzN8cpXccA5UFlWY=; b=c8vjSgMUydzTQd2SB1YRkgqBwEuIIzZ6Pnn3uyaq/STGksHXIjCrbVNJ d/ZBUqlqxTMOF+pf+ViRf6LzAV8eE2i7X1DuXs/KI+OwqClKDzfAaMC1i R9E+nDiykxDHUuxH+7dO/tnarYuot/YhC0X53i8Q0flmVktNsP4V3qph1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAx0Y02rRN+K/2dsb2JhbACmHnOiNJtXhV4EhQ2HBoM7 X-IronPort-AV: E=Sophos;i="4.62,207,1297036800"; d="scan'208";a="268549000" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 22 Feb 2011 16:36:08 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p1MGa3vv010020; Tue, 22 Feb 2011 16:36:08 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Tue, 22 Feb 2011 08:36:08 -0800 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Tue, 22 Feb 2011 08:36:08 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <9809164F-B54C-4865-9134-DC527FA1B982@istaff.org> Date: Tue, 22 Feb 2011 08:35:54 -0800 Message-Id: References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> <4D61A54F.2090006@bogus.com> <4D62B42E.9020003@dougbarton.us> <8D7A4818-D79E-468B-A1AF-38861848C508@istaff.org> <4D62D4B0.7060107@dougbarton.us> <9809164F-B54C-4865-9134-DC527FA1B982@istaff.org> To: John Curran X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 16:35:24 -0000 On Feb 22, 2011, at 8:34 AM, John Curran wrote: > We have yet to hear from a whitelisting party that actually views > this as "stepping on toes" by publication (e.g. Erik Kline noted > ambivalence & that "IETF probably has to publish RFCs that state > warnings about things ...") If some network would be offended by > having this technique written up, it's time for them actually say > that on this list, less we hold publication up for nothing more > than a chimera. hear, hear! From K.Fleischhauer@telekom.de Tue Feb 22 09:35:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549143A6957 for ; Tue, 22 Feb 2011 09:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPKIJBe+geNa for ; Tue, 22 Feb 2011 09:35:05 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id EBF1C3A6940 for ; Tue, 22 Feb 2011 09:35:03 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 22 Feb 2011 18:35:44 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.253]) by he110890 ([10.134.92.131]) with mapi; Tue, 22 Feb 2011 18:35:43 +0100 From: To: , Date: Tue, 22 Feb 2011 18:35:42 +0100 Thread-Topic: [v6ops] Soliciting feedback on draft-livingood-dns-whitelisting-implications Thread-Index: AQHLYZZsVCE0+zqIz0+l2xjka9peKJMs6OYAgLXWlQCAKizzgIAANxgAgAGGMbA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D016D6C45B9@HE111648.emea1.cds.t-internal.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D010C6DB4CF@HE111648.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D016D6C45B9HE111648emea1_" MIME-Version: 1.0 Subject: Re: [v6ops] Soliciting feedback on draft-livingood-dns-whitelisting-implications X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 17:35:09 -0000 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D016D6C45B9HE111648emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Jason, thank you very much for the correction. Of course RFC 4213 is the Dual-Stac= k architecture reference. The text proposal looks fine for us. Best KARSTEN ________________________________ Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Gesendet: Montag, 21. Februar 2011 19:16 An: Fleischhauer, Karsten; v6ops@ietf.org Betreff: Re: [v6ops] Soliciting feedback on draft-livingood-dns-whitelistin= g-implications Hi Karsten and thanks for your review! I think you mean RFC 4213, which I will made a reference to in Section 7.1.= If I have gotten that wrong, please say so. What I propose adding to 7.1 = is the following: //start// Also, it is possible that DNS whitelisting could affect some of the archite= ctural assumptions which underlie parts of Section 2 of [RFC4213] which outlines the dual stack a= pproach to the IPv6 transition. DNS whitelisting could modify the behavior = of the DNS, as described in Section 2.2 of [RFC4213] and could require different sets of DNS serv= ers to be used for hosts that are (using terms from that document) IPv6/IPv= 4 nodes, IPv4-only nodes, and IPv6-only nodes. As such, broad use of DNS wh= itelisting may necessitate the review and/or revision of standards document= s which describe dual-stack and IPv6 operating modes, dual-stack architectu= re generally, and IPv6 transition methods, including but not limited to [RF= C4213]. //end// I'll incorporate your suggestions into a -03 version shortly, unless you wi= sh to see changes to what I proposed. Thanks Jason On 2/21/11 10:28 AM, "K.Fleischhauer@telekom.de" > wrote: Dear Jason, section "7.1 Architectural Implications" should at least contain a hint that with DNS-Whitelisting from an ISP perspective the usage of the Dual-Stack approach as defined in section 2 of RFC4177 as "the most straightforward way for IPv6 nodes to remain compatible with IPv4-only nodes" is only very limited applicable: 1. ISP have to provide different DNS resolver for different customer groups (e.g. IPv4-only customers and Dual-Stack customers/IPv6-only customers), 2. During the dial-in process the membership of an access device/customer to the above mentioned groups has to be identified und depending on the result the DNS resolver addresses (IPv4) has to be provisioned. 3. To meet these requirements a lot of finalized standards has to be reviewed and maybe revised. All this would lead to additional delay and effort for introducing IPv6. Kind regards Karsten Karsten Fleischhauer Deutsche Telekom Netzproduktion GmbH --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D016D6C45B9HE111648emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear=20 Jason,
 
thank you= very much=20 for the correction. Of course RFC 4213 is the Dual-Stack architecture ref= erence.=20
The text = proposal=20 looks fine for us.
 
Best
 
KARSTEN
 

Von: Livingood, Jason=20 [mailto:Jason_Livingood@cable.comcast.com]
Gesendet: Montag, 2= 1.=20 Februar 2011 19:16
An: Fleischhauer, Karsten;=20 v6ops@ietf.org
Betreff: Re: [v6ops] Soliciting feedback on=20 draft-livingood-dns-whitelisting-implications

Hi Karsten and thanks for your review! 

I think you mean RFC 4213, which I will made a reference to in Secti= on=20 7.1.  If I have gotten that wrong, please say so. What I propose add= ing=20 to 7.1 is the following:

//start//
//end//

I'll incorporate your suggestions into a -03 version shortly, unless= you=20 wish to see changes to what I proposed. 

Thanks
Jason
<K.Fleischhauer@telekom.de&g= t;=20 wrote:

Dear Jason,

section "7.1 Architectural Implications" should at least
contain a hint that with DNS-Whitelisting from an ISP perspective<= /DIV>
the usage of the Dual-Stack approach as defined in section 2 of
RFC4177 as "the most straightforward way for IPv6 nodes to remain<= /DIV>
compatible with IPv4-only nodes" is only very limited=20 applicable:

1. ISP have to provide different DNS resolver for different custom= er=20
groups
   (e.g. IPv4-only customers and Dual-Stack=20 customers/IPv6-only
customers),
2. During the dial-in process the membership of an access=20 device/customer
   to the above mentioned groups has to be identified un= d=20 depending
   on the result the DNS resolver addresses (IPv4) has t= o be=20 provisioned.
3. To meet these requirements a lot of finalized standards has to = be=20
reviewed
   and maybe revised.

All this would lead to additional delay and effort for introducing= =20 IPv6.


Kind regards

Karsten

Karsten Fleischhauer

Deutsche Telekom Netzproduktion=20 GmbH
--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D016D6C45B9HE111648emea1_-- From jfesler@yahoo-inc.com Tue Feb 22 09:35:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7370C3A6960 for ; Tue, 22 Feb 2011 09:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.997 X-Spam-Level: X-Spam-Status: No, score=-16.997 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72ezrrBEMUtQ for ; Tue, 22 Feb 2011 09:35:18 -0800 (PST) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id 5A8883A695A for ; Tue, 22 Feb 2011 09:35:18 -0800 (PST) Received: from sp1-ex07cas03.ds.corp.yahoo.com (sp1-ex07cas03.ds.corp.yahoo.com [216.252.116.151]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p1MHZb1P083044; Tue, 22 Feb 2011 09:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1298396137; bh=Y1ba681TP8SsriAN3UeBkxxTmzn1IpWyEi+70pP89wM=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=PbGN2810Cu/EM2BpcMOhIVMR8TUCetaUJP1rpP5itAYamdd6yLtsq7HQ4QA9DwJKw fA41rfObdsLh5ZS5lzIrIFSxArZcm5dSKcQo5pvsZAXa7Ou7k6YU5E5UvAmDED3yOv 5XV9Id5JT8Y9BotRpOT8YVB+Wo4Y4eL7KESzmksI= Received: from SP1-EX07VS01.ds.corp.yahoo.com ([216.252.116.139]) by sp1-ex07cas03.ds.corp.yahoo.com ([216.252.116.151]) with mapi; Tue, 22 Feb 2011 09:35:37 -0800 From: Jason Fesler To: Erik Kline Date: Tue, 22 Feb 2011 09:35:36 -0800 Thread-Topic: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 Thread-Index: AcvStuqZB/2+zyuVRL6lxlWn7JEJ+A== Message-ID: <765C2B42-ECE8-4E1D-B44F-80F6C0E9A0B2@yahoo-inc.com> References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> <4D61A54F.2090006@bogus.com> <4D62B42E.9020003@dougbarton.us> 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_765C2B42ECE84E1DB44F80F6C0E9A0B2yahooinccom_" MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 17:35:19 -0000 --_000_765C2B42ECE84E1DB44F80F6C0E9A0B2yahooinccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1. I'm not offended by the draft in the least. It also won't affect whether or how we do whitelisting. For reasons mentio= ned here, and in the draft. -jason On Feb 21, 2011, at 6:47 PM, Erik Kline wrote: (agreeing with many sentiments) Simply put, if published this draft will do more harm than good. The major sites are already moving forward on wider v6 deployment, including Google, the site that popularized whitelisting. (See http://isoc.org/wp/worldipv6day/, et al) OTOH, sites that genuinely believe that they need to use this technique are going to use it whether this document is released or not. "It works for Google" is a much more persuasiv= e line of reasoning. Releasing this now makes us look like a bunch of old ladies wagging our fingers at recalcitrant children. After going 'round and 'round on this deciding if I should care about this document or not, I ultimately decided "not, not at all". The "manual overhead" complaints are certainly real and well understood at this moment. However, we (Google) have publicly stated that all this will be automated and no communication will be required. Note also that Akamai has publicly declared that they will dynamically, automatically decide when to serve AAAAs and when not to. This is indistinguishble from automated whitelisting. I suspect, therefore, this draft will hold no water with them either, but obviously can't speak for them. In the end, I settled on the opinion that the IETF probably has to publish RFCs that state warnings about things like "geographic load balancing via DNS has the following implications:...", and then everyone who has to go out and do that anyway goes out and does that anyway. In my mind this document is basically in that category. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_765C2B42ECE84E1DB44F80F6C0E9A0B2yahooinccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1.

I'm not offended by the draft in the least.

It also won't affect whether or how we do whitelisting.  For reasons= mentioned here, and in the draft.

-jason





On Feb 21, 2011, at 6:47 PM, Erik Kline wrote:

(agreeing with m= any sentiments)

Simply put, if published t= his draft will do more harm than good. The major
sites are already moving forward on wider v6 deployment, in= cluding Google,
the site that pop= ularized whitelisting. (See
http://isoc.org/wp/worldipv6day/, et al) OTOH, sites that genuinely believe
that they need to use this technique are going to use it whethe= r this
document is released or no= t. "It works for Google" is a much more persuasive
line of reasoning. Releasing this now makes us look like = a bunch of old
ladies wagging our= fingers at recalcitrant children.

After going 'round a= nd 'round on this deciding if I should care about
this document or not, = I ultimately decided "not, not at all".

The "manual overhead" compla= ints are certainly real and well
understood at this moment.  Howeve= r, we (Google) have publicly stated
that all this will be automated and = no communication will be required.

Note also that Akamai has publicl= y declared that they will
dynamically, automatically decide when to serv= e AAAAs and when not to.
This is indistinguishble from automated whitel= isting.  I suspect,
therefore, this draft will hold no water with t= hem either, but
obviously can't speak for them.

In the end, I set= tled on the opinion that the IETF probably has to
publish RFCs that stat= e warnings about things like "geographic load
balancing via DNS has the = following implications:...", and then
everyone who has to go out and do = that anyway goes out and does that
anyway.  In my mind this documen= t is basically in that category.
_______________________________________= ________
v6ops mailing list
v6ops@i= etf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --_000_765C2B42ECE84E1DB44F80F6C0E9A0B2yahooinccom_-- From dougb@dougbarton.us Tue Feb 22 10:23:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346643A695D for ; Tue, 22 Feb 2011 10:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sV-R+pFI3Phn for ; Tue, 22 Feb 2011 10:22:59 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id CF06E3A6959 for ; Tue, 22 Feb 2011 10:22:58 -0800 (PST) Received: (qmail 21232 invoked by uid 399); 22 Feb 2011 18:23:38 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 22 Feb 2011 18:23:38 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D63FF29.80409@dougbarton.us> Date: Tue, 22 Feb 2011 10:23:37 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Curran References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> <4D61A54F.2090006@bogus.com> <4D62B42E.9020003@dougbarton.us> <8D7A4818-D79E-468B-A1AF-38861848C508@istaff.org> <4D62D4B0.7060107@dougbarton.us> <9809164F-B54C-4865-9134-DC527FA1B982@istaff.org> In-Reply-To: <9809164F-B54C-4865-9134-DC527FA1B982@istaff.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 18:23:00 -0000 On 02/22/2011 08:34, John Curran wrote: > The publication itself is deemed useful by some of the WG. > > We have yet to hear from a whitelisting party that actually views > this as "stepping on toes" by publication (e.g. Erik Kline noted > ambivalence& that "IETF probably has to publish RFCs that state > warnings about things ...") If some network would be offended by > having this technique written up, it's time for them actually say > that on this list, less we hold publication up for nothing more > than a chimera. The problem is that the people I'm speaking about don't bother participating anymore because the IETF echo chamber keeps publishing stuff like this that's at best irrelevant (as we've heard from 2 relevant operators now) and at worst other things that are actively opposed to operational needs *cough*dhcpv6*cough*. John, you've been a participant in the threads on the NANOG list where these exact topics (meaning, frustration with the IETF and its processes) are discussed, the frustration is expressed, and the operators have said point blank, "We don't bother with IETF anymore, they're not relevant." You(pl.) can continue to sit on your hands and say, "Well if the operators want input they have to come here and give it" or you can listen to what some of the few operators left on the list are saying. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From joelja@bogus.com Tue Feb 22 10:46:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24CF23A68D8 for ; Tue, 22 Feb 2011 10:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOl4eLfJGnfR for ; Tue, 22 Feb 2011 10:46:09 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 622B73A68C8 for ; Tue, 22 Feb 2011 10:46:08 -0800 (PST) Received: from localhost (m340536d0.tmodns.net [208.54.5.52]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p1MIkd6f059858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Feb 2011 18:46:44 GMT (envelope-from joelja@bogus.com) Date: Tue, 22 Feb 2011 10:46:20 -0800 Message-ID: From: Joel Jaeggli To: Doug Barton , John Curran MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Tue, 22 Feb 2011 18:46:46 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 18:46:10 -0000 Rm9yIHRoZSByZWNvcmQgdGhlIGF1dGhvciBpcyBhbiBvcGVyYXRvci4gCgpGb3IgbXlzZWxmIEkg ZG9uJ3QgdGhpbmsgdGhlIGFyYml0YXJ5IGJhbGtpemF0aW9uIG9mIHRoZSBjb21tdW5pdHkgaW50 byBvcGVyYXRvciB2cyBub24gb3BlcmF0b3IgZXNwZWNpYWxseSBpbiBhbiBvcHMgZ3JvdXAgaXMg dGVycmlibHkgaGVhbHRoeS4gSSB3b3JrIGZvciBhIGNvbnRlbnQgcHJvdmlkZXIsIHdlIHVzZSBk bnMgYmFzZWQgZ2xiIGFuZCB3aGlsZSAgSSB0aGluayB0aGlzIGRvY3VtZW50IGlzIHVzZWZ1bCwg aXQgd2lsbCBpbiBubyB3YXkgcHJlY2x1ZGUgYW55IGJ1c2luZXNzIGRlY2lzaW9uIHRoYXQgd2Ug bWFrZSBhYm91dCB0aGUgdXNlIG9yIGxhY2sgdGhlcmVvZiBvZiB0aGUgc2VsZWN0aXZlIHJldHVy biBvZiBhYWFhIHJlY29yZHMuCgpBcyBvcGVyYXRvcnMgd2UgZG9uJ3QgYWxsIHNwZWFrIHdlIG9u ZSB2b2ljZS4KClRoYW5rcwpKb2VsCgpEb3VnIEJhcnRvbiA8ZG91Z2JAZG91Z2JhcnRvbi51cz4g d3JvdGU6Cgo+T24gMDIvMjIvMjAxMSAwODozNCwgSm9obiBDdXJyYW4gd3JvdGU6Cj4+IFRoZSBw dWJsaWNhdGlvbiBpdHNlbGYgaXMgZGVlbWVkIHVzZWZ1bCBieSBzb21lIG9mIHRoZSBXRy4KPj4K Pj4gV2UgaGF2ZSB5ZXQgdG8gaGVhciBmcm9tIGEgd2hpdGVsaXN0aW5nIHBhcnR5IHRoYXQgYWN0 dWFsbHkgdmlld3MKPj4gdGhpcyBhcyAic3RlcHBpbmcgb24gdG9lcyIgYnkgcHVibGljYXRpb24g KGUuZy4gRXJpayBLbGluZSBub3RlZAo+PiBhbWJpdmFsZW5jZSYgIHRoYXQgIklFVEYgcHJvYmFi bHkgaGFzIHRvIHB1Ymxpc2ggUkZDcyB0aGF0IHN0YXRlCj4+IHdhcm5pbmdzIGFib3V0IHRoaW5n cyAuLi4iKSAgSWYgc29tZSBuZXR3b3JrIHdvdWxkIGJlIG9mZmVuZGVkIGJ5Cj4+IGhhdmluZyB0 aGlzIHRlY2huaXF1ZSB3cml0dGVuIHVwLCBpdCdzIHRpbWUgZm9yIHRoZW0gYWN0dWFsbHkgc2F5 Cj4+IHRoYXQgb24gdGhpcyBsaXN0LCBsZXNzIHdlIGhvbGQgcHVibGljYXRpb24gdXAgZm9yIG5v dGhpbmcgbW9yZQo+PiB0aGFuIGEgY2hpbWVyYS4KPgo+VGhlIHByb2JsZW0gaXMgdGhhdCB0aGUg cGVvcGxlIEknbSBzcGVha2luZyBhYm91dCBkb24ndCBib3RoZXIgCj5wYXJ0aWNpcGF0aW5nIGFu eW1vcmUgYmVjYXVzZSB0aGUgSUVURiBlY2hvIGNoYW1iZXIga2VlcHMgcHVibGlzaGluZyAKPnN0 dWZmIGxpa2UgdGhpcyB0aGF0J3MgYXQgYmVzdCBpcnJlbGV2YW50IChhcyB3ZSd2ZSBoZWFyZCBm cm9tIDIgCj5yZWxldmFudCBvcGVyYXRvcnMgbm93KSBhbmQgYXQgd29yc3Qgb3RoZXIgdGhpbmdz IHRoYXQgYXJlIGFjdGl2ZWx5IAo+b3Bwb3NlZCB0byBvcGVyYXRpb25hbCBuZWVkcyAqY291Z2gq ZGhjcHY2KmNvdWdoKi4KPgo+Sm9obiwgeW91J3ZlIGJlZW4gYSBwYXJ0aWNpcGFudCBpbiB0aGUg dGhyZWFkcyBvbiB0aGUgTkFOT0cgbGlzdCB3aGVyZSAKPnRoZXNlIGV4YWN0IHRvcGljcyAobWVh bmluZywgZnJ1c3RyYXRpb24gd2l0aCB0aGUgSUVURiBhbmQgaXRzIAo+cHJvY2Vzc2VzKSBhcmUg ZGlzY3Vzc2VkLCB0aGUgZnJ1c3RyYXRpb24gaXMgZXhwcmVzc2VkLCBhbmQgdGhlIAo+b3BlcmF0 b3JzIGhhdmUgc2FpZCBwb2ludCBibGFuaywgIldlIGRvbid0IGJvdGhlciB3aXRoIElFVEYgYW55 bW9yZSwgCj50aGV5J3JlIG5vdCByZWxldmFudC4iCj4KPllvdShwbC4pIGNhbiBjb250aW51ZSB0 byBzaXQgb24geW91ciBoYW5kcyBhbmQgc2F5LCAiV2VsbCBpZiB0aGUgCj5vcGVyYXRvcnMgd2Fu dCBpbnB1dCB0aGV5IGhhdmUgdG8gY29tZSBoZXJlIGFuZCBnaXZlIGl0IiBvciB5b3UgY2FuIAo+ bGlzdGVuIHRvIHdoYXQgc29tZSBvZiB0aGUgZmV3IG9wZXJhdG9ycyBsZWZ0IG9uIHRoZSBsaXN0 IGFyZSBzYXlpbmcuCj4KPgo+RG91Zwo+Cj4tLSAKPgo+CU5vdGhpbicgZXZlciBkb2Vzbid0IGNo YW5nZSwgYnV0IG5vdGhpbicgY2hhbmdlcyBtdWNoLgo+CQkJLS0gT0sgR28KPgo+CUJyZWFkdGgg b2YgSVQgZXhwZXJpZW5jZSwgYW5kIGRlcHRoIG9mIGtub3dsZWRnZSBpbiB0aGUgRE5TLgo+CVlv dXJzIGZvciB0aGUgcmlnaHQgcHJpY2UuICA6KSAgaHR0cDovL1N1cGVyc2V0U29sdXRpb25zLmNv bS8KPgo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPnY2 b3BzIG1haWxpbmcgbGlzdAo+djZvcHNAaWV0Zi5vcmcKPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdjZvcHMKPgo= From jhw@apple.com Tue Feb 22 10:57:30 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96FFB3A67ED for ; Tue, 22 Feb 2011 10:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vYAGeWqG+n1 for ; Tue, 22 Feb 2011 10:57:29 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id EC5CC3A6781 for ; Tue, 22 Feb 2011 10:57:29 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 0116DD3C2738 for ; Tue, 22 Feb 2011 10:58:15 -0800 (PST) X-AuditID: 11807134-b7c40ae000006cb9-f3-4d6407468065 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with SMTP id A0.8A.27833.647046D4; Tue, 22 Feb 2011 10:58:14 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.15.108] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LH100JZR8OVZH40@elliott.apple.com> for v6ops@ietf.org; Tue, 22 Feb 2011 10:58:14 -0800 (PST) From: james woodyatt In-reply-to: Date: Tue, 22 Feb 2011 10:58:06 -0800 Message-id: References: To: Joel Jaeggli , Doug Barton X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 18:57:30 -0000 On Feb 22, 2011, at 10:46 AM, Joel Jaeggli wrote: > On Feb 22, 2011, at 10:23 AM, Doug Barton wrote: >> >> the operators have said point blank, "We don't bother with IETF anymore, they're not relevant." > > For myself I don't think the arbitary balkization of the community into operator vs non operator especially in an ops group is terribly healthy. I don't participate in NANOG. Not an operator. Not a content provider. See my .signature file. I participate in IETF. If NANOG thinks people in the Internet engineering community like me are "not relevant anymore," then that says a lot more about the acoustical properties of *their* chambers than it does about ours. While I haven't reviewed the draft thoroughly, I have read it, and I do support it generally. Though, I expect that Erik Kline has characterized the nature of the draft accurately. -- james woodyatt member of technical staff, core os networking From dougb@dougbarton.us Tue Feb 22 11:01:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF2453A67ED for ; Tue, 22 Feb 2011 11:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AD88JHene0gW for ; Tue, 22 Feb 2011 11:01:21 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 670113A697D for ; Tue, 22 Feb 2011 11:01:07 -0800 (PST) Received: (qmail 21583 invoked by uid 399); 22 Feb 2011 19:01:47 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 22 Feb 2011 19:01:47 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D640819.90505@dougbarton.us> Date: Tue, 22 Feb 2011 11:01:45 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: james woodyatt References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 19:01:22 -0000 On 02/22/2011 10:58, james woodyatt wrote: > I participate in IETF. If NANOG thinks people in the Internet engineering community like me are "not relevant anymore," then that says a lot more about the acoustical properties of*their* chambers than it does about ours. IMO the problem generally is that neither side is (genuinely) listening to the other, as opposed to just waiting for the other to stop talking so that they can be told why they're wrong. Your message here is a good example. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From fred@cisco.com Tue Feb 22 11:06:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5713A68EA for ; Tue, 22 Feb 2011 11:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.516 X-Spam-Level: X-Spam-Status: No, score=-110.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTwo2sz-nPMU for ; Tue, 22 Feb 2011 11:05:59 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 457113A67F9 for ; Tue, 22 Feb 2011 11:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=757; q=dns/txt; s=iport; t=1298401604; x=1299611204; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=BjDP/bZlyh4q+udeXpQ87JpVhG0dWCj7V4oyrBNdyN4=; b=LT+6wQxxkuuyTvztBLc/Tvuwj4uZlSzm1PhbqzQH9nikK0zQpVz5y86w AZ552D+ziE5WIzCsdVYRk69/NBKQf73QxXaQxrr1hFH/WW3bI5/5igmaG oV2U+6i5bCXlFmZ58UcBLAelYJglU9syglPi0y4LKsVw8bDC6eqA3aFcS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH+XY02rRN+J/2dsb2JhbACmHXOiPptahV4EhQ2HBoM7 X-IronPort-AV: E=Sophos;i="4.62,207,1297036800"; d="scan'208";a="333634653" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 22 Feb 2011 19:06:44 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p1MJ6dep013081; Tue, 22 Feb 2011 19:06:44 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Tue, 22 Feb 2011 11:06:44 -0800 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Tue, 22 Feb 2011 11:06:44 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D640819.90505@dougbarton.us> Date: Tue, 22 Feb 2011 11:06:29 -0800 Message-Id: <71E6AC75-42A8-422F-B915-569293C6B5F3@cisco.com> References: <4D640819.90505@dougbarton.us> To: Doug Barton , james woodyatt X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 19:06:00 -0000 On Feb 22, 2011, at 11:01 AM, Doug Barton wrote: > On 02/22/2011 10:58, james woodyatt wrote: >> I participate in IETF. If NANOG thinks people in the Internet = engineering community like me are "not relevant anymore," then that says = a lot more about the acoustical properties of*their* chambers than it = does about ours. >=20 > IMO the problem generally is that neither side is (genuinely) = listening to the other, as opposed to just waiting for the other to stop = talking so that they can be told why they're wrong. Your message here is = a good example. So now you're both doing it. I, speaking for myself, would be much = happier if we could return to technical topics. "Mine is bigger" = discussions are best taken offline.= From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Feb 22 13:03:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817AF3A6938 for ; Tue, 22 Feb 2011 13:03:15 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SToOq5BfsIuk for ; Tue, 22 Feb 2011 13:03:14 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id D3A293A67F1 for ; Tue, 22 Feb 2011 13:03:13 -0800 (PST) Received: from 219-90-145-108.ip.adam.com.au ([219.90.145.108] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PrzOl-0001OV-AH; Wed, 23 Feb 2011 07:33:55 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 446EF3B337; Wed, 23 Feb 2011 07:33:54 +1030 (CST) Date: Wed, 23 Feb 2011 07:33:53 +1030 From: Mark Smith To: Doug Barton Message-ID: <20110223073353.5931eab0@opy.nosense.org> In-Reply-To: <4D63FF29.80409@dougbarton.us> References: <4D4F6887.7050203@bogus.com> <4D5814F9.3070800@bogus.com> <4D61A36E.4030708@bogus.com> <4D61A54F.2090006@bogus.com> <4D62B42E.9020003@dougbarton.us> <8D7A4818-D79E-468B-A1AF-38861848C508@istaff.org> <4D62D4B0.7060107@dougbarton.us> <9809164F-B54C-4865-9134-DC527FA1B982@istaff.org> <4D63FF29.80409@dougbarton.us> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: John Curran , IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 21:03:15 -0000 On Tue, 22 Feb 2011 10:23:37 -0800 Doug Barton wrote: > On 02/22/2011 08:34, John Curran wrote: > > The publication itself is deemed useful by some of the WG. > > > > We have yet to hear from a whitelisting party that actually views > > this as "stepping on toes" by publication (e.g. Erik Kline noted > > ambivalence& that "IETF probably has to publish RFCs that state > > warnings about things ...") If some network would be offended by > > having this technique written up, it's time for them actually say > > that on this list, less we hold publication up for nothing more > > than a chimera. > > The problem is that the people I'm speaking about don't bother > participating anymore because the IETF echo chamber keeps publishing > stuff like this that's at best irrelevant (as we've heard from 2 > relevant operators now) and at worst other things that are actively > opposed to operational needs *cough*dhcpv6*cough*. > I'm an operator. My opinion is that the operators who complain are those that don't bother spending the time properly understanding the problem, including the scope of the scenarios that the solution needs to address, or reading Internet Drafts where the problem is usually first explained. It is my experience that most operators I've worked with don't read RFCs at all, despite them being quite readable. They just don't seem to be interested in advancing their understanding of their chosen profession. Participation is not announcing your opinion and then complaining when it isn't blindly accepted. A bit off topic, however DHCPv6 actually only really exists because operators wanted it to. I don't think there is no strong functional need for a stateful, database driven autoconfiguration method in a networking protocol - it's just that that is how it was done in IPv4, because keeping it as an ancestor of BOOTP probably made sense, and IPv4's node addressing bits couldn't really facilitate any other mechanism. The people who object to DHCPv6 not being able to be used for all addressing aren't recognising there is a requirement (ie. they're not bothering to understanding the problem) for a very light weight stateless automatic addressing system for use on, for example, low powered and resource constrained embedded systems. RAs exist because these stateless nodes need to learn of available routers and other information to autoconfigure themselves. As statefull addressing also exists, there needs to be a mechanism to express to end-nodes the addressing model being used on the link - RAs serve that purpose too. People argue DHCPv6 should be able to supply the default gateway, however I think they're ignoring the fact that RAs or something similar, which makes most sense to be issued by onlink routers, still need to exist to express which of the stateless / statefull onlink addressing model is in use. Duplication of functionality just creates more complexity. RAs are always going to be needed, so what is the value in creating equivalent default gateway functionality DHCPv6? > John, you've been a participant in the threads on the NANOG list where > these exact topics (meaning, frustration with the IETF and its > processes) are discussed, the frustration is expressed, and the > operators have said point blank, "We don't bother with IETF anymore, > they're not relevant." > > You(pl.) can continue to sit on your hands and say, "Well if the > operators want input they have to come here and give it" or you can > listen to what some of the few operators left on the list are saying. > > > Doug > > -- > > Nothin' ever doesn't change, but nothin' changes much. > -- OK Go > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jason_livingood@cable.comcast.com Tue Feb 22 20:23:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9923A69B6 for ; Tue, 22 Feb 2011 20:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.413 X-Spam-Level: X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=2.049, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VV38rQoDJcLU for ; Tue, 22 Feb 2011 20:23:10 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id F39443A69B5 for ; Tue, 22 Feb 2011 20:23:09 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.114549049; Tue, 22 Feb 2011 23:23:51 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Tue, 22 Feb 2011 23:23:51 -0500 From: "Livingood, Jason" To: Joel Jaeggli Thread-Topic: comments: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 Thread-Index: AQHL0xF5E8WxHY01xEqayz+BpYe02g== Date: Wed, 23 Feb 2011 04:23:51 +0000 Message-ID: In-Reply-To: <4D61A46A.50708@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.12] Content-Type: multipart/alternative; boundary="_000_C987D6AA19823jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] comments: Re: WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 04:23:11 -0000 --_000_C987D6AA19823jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you very much for the suggested changes. These were all good things t= o tighten up the language of the draft. I greatly appreciate your thorough = review and detailed feedback on changes to the document. Your changes have been included into a =9603 version, which I will post soo= n (I have a couple of other bits of WGLC feedback to close out). Thank you for the review! Regards Jason On 2/20/11 6:31 PM, "Joel Jaeggli" > wrote: these are a list of proposed edits from a deep read of the document. I don't thing the really change the content, just tighten up the language. These were done with openoffice, the ODF version is probably higher quality than the word version as a result. the changes were recorded so you should be able to see them as differences from the text. or if you can shoot me the source file I can commit them directly. obviously these are just my opinion and you can accept or not. joel --_000_C987D6AA19823jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6641BBF6A7BBFB4A81393C79F3BF6ED3@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Thank you very much for the suggested changes. These were all good thi= ngs to tighten up the language of the draft. I greatly appreciate your thor= ough review and detailed feedback on changes to the document. 

Your changes have been included into a =9603 version, which I will pos= t soon (I have a couple of other bits of WGLC feedback to close out).

Thank you for the review!

Regards
Jason

On 2/20/11 6:31 PM, "Joel Jaeggli" <joelja@bogus.com> wrote:

these are a list of proposed edits from a deep read of the document. I=
don't thing the really change the content, just tighten up the languag= e.

These were done with openoffice, the ODF version is probably higher
quality than the word version as a result. the changes were recorded s= o
you should be able to see them as differences from the text. or if you=
can shoot me the source file I can commit them directly.

obviously these are just my opinion and you can accept or not.

joel

--_000_C987D6AA19823jasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue Feb 22 20:23:30 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98DA3A69B8 for ; Tue, 22 Feb 2011 20:23:30 -0800 (PST) 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=1.652, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpAPt26sjYk9 for ; Tue, 22 Feb 2011 20:23:29 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id D67DF3A69C4 for ; Tue, 22 Feb 2011 20:23:28 -0800 (PST) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.114549058; Tue, 22 Feb 2011 23:24:11 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Tue, 22 Feb 2011 23:24:11 -0500 From: "Livingood, Jason" To: "K.Fleischhauer@telekom.de" , "v6ops@ietf.org" Thread-Topic: [v6ops] Soliciting feedback on draft-livingood-dns-whitelisting-implications Thread-Index: AQHLYZZsVCE0+zqIz0+l2xjka9peKJMs6OYAgLXWlQCAKizzgIAANxgAgAGGMbCAAEo7AA== Date: Wed, 23 Feb 2011 04:24:09 +0000 Message-ID: In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D016D6C45B9@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.12] Content-Type: multipart/alternative; boundary="_000_C9899B7E19CC6jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: Re: [v6ops] Soliciting feedback on draft-livingood-dns-whitelisting-implications X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 04:23:31 -0000 --_000_C9899B7E19CC6jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Cool. This text will then appear in the =9603 update, which I will post soo= n. Thanks! Jason On 2/22/11 12:35 PM, "K.Fleischhauer@telekom.de" > wrote= : Dear Jason, thank you very much for the correction. Of course RFC 4213 is the Dual-Stac= k architecture reference. The text proposal looks fine for us. Best KARSTEN ________________________________ Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Gesendet: Montag, 21. Februar 2011 19:16 An: Fleischhauer, Karsten; v6ops@ietf.org Betreff: Re: [v6ops] Soliciting feedback on draft-livingood-dns-whitelistin= g-implications Hi Karsten and thanks for your review! I think you mean RFC 4213, which I will made a reference to in Section 7.1.= If I have gotten that wrong, please say so. What I propose adding to 7.1 = is the following: //start// Also, it is possible that DNS whitelisting could affect some of the archite= ctural assumptions which underlie parts of Section 2 of [RFC4213] which outlines the dual stack a= pproach to the IPv6 transition. DNS whitelisting could modify the behavior = of the DNS, as described in Section 2.2 of [RFC4213] and could require different sets of DNS serv= ers to be used for hosts that are (using terms from that document) IPv6/IPv= 4 nodes, IPv4-only nodes, and IPv6-only nodes. As such, broad use of DNS wh= itelisting may necessitate the review and/or revision of standards document= s which describe dual-stack and IPv6 operating modes, dual-stack architectu= re generally, and IPv6 transition methods, including but not limited to [RF= C4213]. //end// I'll incorporate your suggestions into a -03 version shortly, unless you wi= sh to see changes to what I proposed. Thanks Jason On 2/21/11 10:28 AM, "K.Fleischhauer@telekom.de" > wrote: Dear Jason, section "7.1 Architectural Implications" should at least contain a hint that with DNS-Whitelisting from an ISP perspective the usage of the Dual-Stack approach as defined in section 2 of RFC4177 as "the most straightforward way for IPv6 nodes to remain compatible with IPv4-only nodes" is only very limited applicable: 1. ISP have to provide different DNS resolver for different customer groups (e.g. IPv4-only customers and Dual-Stack customers/IPv6-only customers), 2. During the dial-in process the membership of an access device/customer to the above mentioned groups has to be identified und depending on the result the DNS resolver addresses (IPv4) has to be provisioned. 3. To meet these requirements a lot of finalized standards has to be reviewed and maybe revised. All this would lead to additional delay and effort for introducing IPv6. Kind regards Karsten Karsten Fleischhauer Deutsche Telekom Netzproduktion GmbH _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_C9899B7E19CC6jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2766517B045DED49B86B15C7FBA587C3@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Cool. This text will then appear in the =9603 update, which I will pos= t soon.

Thanks!
Jason



Dea= r Jason,
 
tha= nk you very much for the correction. Of course RFC 4213 is the Dual-Stack architecture reference.
The= text proposal looks fine for us.
 
Bes= t
 
KAR= STEN
 

Von: Livingood, Jason [mailto:Jason_Livingood@cable.comca= st.com]
Gesendet: Montag, 21. Februar 2011 19:16
An: Fleischhauer, Karsten; v6ops@i= etf.org
Betreff: Re: [v6ops] Soliciting feedback on draft-livingood-dns-whit= elisting-implications

Hi Karsten and thanks for your review! 

I think you mean RFC 4213, which I will made a reference to in Section= 7.1.  If I have gotten that wrong, please say so. What I propose addi= ng to 7.1 is the following:

//start//
[RFC4213] which outlines the dual stack approach to the IPv6 transition. DNS whitelisting could mod= ify the behavior of the DNS, as described in Section 2.2 of [RFC4213] = ;and could require different sets of DNS servers to be used for hosts that are = (using terms from that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6= -only nodes. As such, broad use of DNS whitelisting may necessitate the rev= iew and/or revision of standards documents which describe dual-stack and IPv6 operating modes, dual-stack a= rchitecture generally, and IPv6 transition methods, including but not limit= ed to [RFC4213].
//end//

I'll incorporate your suggestions into a -03 version shortly, unless y= ou wish to see changes to what I proposed. 

Thanks
Jason

On 2/21/11 10:28 AM, "K.Fleischhauer@telekom.de"

Dear Jason,

section "7.1 Architectural Implications" should at least
contain a hint that with DNS-Whitelisting from an ISP perspective
the usage of the Dual-Stack approach as defined in section 2 of
RFC4177 as "the most straightforward way for IPv6 nodes to remain=
compatible with IPv4-only nodes" is only very limited applicable:=

1. ISP have to provide different DNS resolver for different customer <= /div>
groups
   (e.g. IPv4-only customers and Dual-Stack customers/IPv6-o= nly
customers),
2. During the dial-in process the membership of an access device/custo= mer
   to the above mentioned groups has to be identified und de= pending
   on the result the DNS resolver addresses (IPv4) has to be= provisioned.
3. To meet these requirements a lot of finalized standards has to be <= /div>
reviewed
   and maybe revised.

All this would lead to additional delay and effort for introducing IPv= 6.


Kind regards

Karsten

Karsten Fleischhauer

Deutsche Telekom Netzproduktion GmbH
_______________________________________________ v6ops mailing list v6ops@ietf.org = https://www.ietf.org/mailman/listinfo/v6ops
--_000_C9899B7E19CC6jasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue Feb 22 20:23:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148103A69D0 for ; Tue, 22 Feb 2011 20:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.285 X-Spam-Level: X-Spam-Status: No, score=-106.285 tagged_above=-999 required=5 tests=[AWL=1.577, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvGG9HyBCN5B for ; Tue, 22 Feb 2011 20:23:37 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id CA6133A69B8 for ; Tue, 22 Feb 2011 20:23:36 -0800 (PST) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.114549062; Tue, 22 Feb 2011 23:24:19 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Tue, 22 Feb 2011 23:24:19 -0500 From: "Livingood, Jason" To: Suresh Krishnan , IPv6 Ops WG Thread-Topic: WGLC Review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 Thread-Index: AQHL0hnQspYdU6XZhUG0e7EINKf0opQOJ18A Date: Wed, 23 Feb 2011 04:24:18 +0000 Message-ID: In-Reply-To: <4D62EC35.9060500@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.12] Content-Type: multipart/alternative; boundary="_000_C9899BA519CC7jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: Re: [v6ops] WGLC Review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 04:23:39 -0000 --_000_C9899BA519CC7jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Suresh =96 Thanks for your review and detailed, specific feedback below. Yo= ur suggestions have been incorporated into a =9603 update, which I will pub= lish soon. Please see specific comments inline below for responses to each = of the points you raise. Thank you! Jason On 2/21/11 5:50 PM, "Suresh Krishnan" > wrote: Hi Jason, Thanks for putting together this draft. It provides a very good overview of the whitelisting process. I did have a few comments though * Meta comment =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * This draft does not mention using a different (sub-)domain name as an alternative to whitelisting (e.g. as done in http://ipv6.google.com/ or http://www.v6.facebook.com/). I am not sure if you wanted to cover this here, but as the draft intends to also cover "what alternatives may exist", I think it may be useful to do so. [JL] Excellent suggestion! I have added a new sub-section to the Solutions = part of the document. Here is how it will appear in the =9603 version. Plea= se let me know if you think this is sufficient or should be modified. Gain Experience Using IPv6 Transition Names Another alternative is for domains to gain experience using an FQDN which h= as become common for domains beginning the transition to IPv6; ipv6.example= .com and www.ipv6.example.com. This can be a way for a domain to gain IPv6 = experience and increase IPv6 use on a relatively controlled basis, and to i= nform any plans for DNS whitelisting with experience. * Major =3D=3D=3D=3D=3D=3D=3D * Section 2 (Figures 1 and 2) I think the system logic (Fig 1) and the associated diagram (Fig 2) being described here are not correct. They ignore the fact that the DNS query is for a specific type (A or AAAA but not both) and the draft needs to mainly describe what happens when a AAAA query is received. I think it would greatly simplify things if these two were redone. e.g. Here is what I think the system logic should be 1: The authoritative DNS server for example.com receives a DNS AAA query for www.example.com, for which AAAA (IPv6) address records exist. 2: The authoritative DNS server examines the IP address of the DNS recursive resolver sending the query. 3: The authoritative DNS server checks this IP address against the access control list (ACL) that is the DNS whitelist. 4: If the DNS recursive resolver's IP address IS listed in the ACL, then the response to that specific DNS recursive resolver can contain AAAA (IPv6) address records. 5: If the DNS recursive resolver's IP address IS NOT listed in the ACL, then the response to that specific DNS recursive resolver can cannot contain AAAA (IPv6) address records. The server should return a response with the response code (RCODE) being set to 0 (No Error) with an empty answer section. [JL] Good feedback. I also received some other feedback on that section and= so have synthesized it as follows below. Let me know if you think this is = okay of course. 1. The authoritative DNS server for example.com receives DNS queries for th= e A (IPv4) and AAAA (IPv6) address resource records for the FQDN www.exampl= e.com, for which AAAA (IPv6) resource records exist. 2. The authoritative DNS server examines the IP address of the DNS recursiv= e resolver sending the AAAA (IPv6) query. 3. The authoritative DNS server checks this IP address against the access c= ontrol list (ACL) that is the DNS whitelist. 4 . If the DNS recursive resolver's IP address IS matched in the ACL, then = the response to that specific DNS recursive resolver can contain AAAA (IPv6= ) address resource records. 5. If the DNS recursive resolver's IP address IS NOT matched in the ACL, th= en the response to that specific DNS recursive resolver cannot contain AAAA= (IPv6) address resource records. In this case, the server should return a = response with the response code (RCODE) being set to 0 (No Error) with an e= mpty answer section for the AAAA record query. * Editorial =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * The reference names are too long and they obstruct the flow of the document. e.g. "Network World Article on IETF 77 DNSOP WG Presentation" Is it possible to shorten them? [JL] Sure thing =96 good suggestion. Also, in my recent experience, the RFC= Editor will also look at those and they usually shorten them all further (= or in different ways that are consistent in form across many documents). In= any case, I have shortened all the non-RFC reference names. * Section 11 s/advise the end use/advise the end user/ [JL] Good catch! Corrected. Thanks again! Jason Cheers Suresh On 11-02-13 12:29 PM, Joel Jaeggli wrote: The halfway point has been reached, please get your feedback in by monday the 21st... On 2/6/11 7:35 PM, Joel Jaeggli wrote: This announcement is to serve as the beginning of the WGLC for: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implicatio= ns-02 WGLC runs from Monday Feb 7th to Monday Feb 21st. The 01 version of this document received a lot of good feedback on this list which has been incorporated into this version of the draft. joelja _______________________________________________ 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 --_000_C9899BA519CC7jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <071B4CB1AA3B9147AB6AFAC008B74470@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Suresh =96 Thanks for your review and detailed, specific feedback belo= w. Your suggestions have been incorporated into a =9603 update, which I wil= l publish soon. Please see specific comments inline below for responses to = each of the points you raise. 

Thank you!
Jason

On 2/21/11 5:50 PM, "Suresh Krishnan" <suresh.krishnan@ericsson.com> wrote:

Hi Jason,
   Thanks for putting together this draft. It provides a ver= y good
overview of the whitelisting process. I did have a few comments though=

* Meta comment
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

* This draft does not mention using a different (sub-)domain name as a= n
alternative to whitelisting (e.g. as done in http://ipv6.google.com/ or
here, but as the draft intends to also cover "what alternatives m= ay
exist", I think it may be useful to do so.

[JL] Excellent suggestion! I have added a new sub-section to the Solut= ions part of the document. Here is how it will appear in the =9603 version.= Please let me know if you think this is sufficient or should be modified.<= /div>

Gain Experience Using IPv6 Transition Names
Another alternative is for domains to gain experience using an FQDN= which has become common for domains beginning the transition to IPv6; ipv6= .example.com and www.ipv6.example.com. This can be a way for a domain to ga= in IPv6 experience and increase IPv6 use on a relatively controlled basis, and to inform any plans for DNS= whitelisting with experience.


* Major
=3D=3D=3D=3D=3D=3D=3D

* Section 2 (Figures 1 and 2)

I think the system logic (Fig 1) and the associated diagram (Fig 2)
being described here are not correct. They ignore the fact that the DN= S
query is for a specific type (A or AAAA but not both) and the draft
needs to mainly describe what happens when a AAAA query is received. I=
think it would greatly simplify things if these two were redone. e.g. =
Here is what I think the system logic should be

    1: The authoritative DNS server for example.co= m receives a DNS
       AAA query for www.example.com, fo= r which AAAA
       (IPv6) address records exist.
    2: The authoritative DNS server examines the I= P address of the DNS
       recursive resolver sending the qu= ery.
    3: The authoritative DNS server checks this IP= address against the
       access control list (ACL) that is= the DNS whitelist.
    4: If the DNS recursive resolver's IP address = IS listed in the ACL,
       then the response to that specifi= c DNS recursive resolver can
       contain AAAA (IPv6) address recor= ds.
    5: If the DNS recursive resolver's IP address = IS NOT listed in the
       ACL, then the response to that sp= ecific DNS recursive resolver
       can cannot contain AAAA (IPv6) ad= dress records. The server should
       return a response with the respon= se code (RCODE) being set to 0
       (No Error) with an empty answer s= ection.

[JL] Good feedback. I also received some other feedback on that sectio= n and so have synthesized it as follows below. Let me know if you think thi= s is okay of course.

1. The authoritative DNS server for example.com receives DNS queries f= or the A (IPv4) and AAAA (IPv6) address resource records for the FQDN www.e= xample.com, for which AAAA (IPv6) resource records exist.
2. The authoritative DNS server examines the IP address of the DNS rec= ursive resolver sending the AAAA (IPv6) query.
3. The authoritative DNS server checks this IP address against the acc= ess control list (ACL) that is the DNS whitelist.
4 . If the DNS recursive resolver's IP address IS matched in the ACL, = then the response to that specific DNS recursive resolver can contain AAAA = (IPv6) address resource records.
5. If the DNS recursive resolver's IP address IS NOT matched in the AC= L, then the response to that specific DNS recursive resolver cannot contain= AAAA (IPv6) address resource records. In this case, the server should retu= rn a response with the response code (RCODE) being set to 0 (No Error) with an empty answer section for th= e AAAA record query.

* Editorial
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

* The reference names are too long and they obstruct the flow of the <= /div>
document.  e.g. "Network World Article on IETF 77 DNSOP= WG Presentation"
Is it possible to shorten them?

[JL] Sure thing =96 good suggestion. Also, in my recent experience, th= e RFC Editor will also look at those and they usually shorten them all furt= her (or in different ways that are consistent in form across many documents= ). In any case, I have shortened all the non-RFC reference names.

* Section 11

s/advise the end use/advise the end user/

[JL] Good catch! Corrected.

Thanks again!
Jason


Cheers
Suresh

On 11-02-13 12:29 PM, Joel Jaeggli wrote:
The halfway point has been reached, please get your feedback in by
monday the 21st...
On 2/6/11 7:35 PM, Joel Jaeggli wrote:
This announcement is to serve as the beginning of the WGLC for:

draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02

WGLC runs from Monday Feb 7th to Monday Feb 21st.

The 01 version of this document received a lot of good feedback on thi= s
list which has been incorporated into this version of the draft.

joelja
_______________________________________________
v6ops mailing list

_______________________________________________
v6ops mailing list


--_000_C9899BA519CC7jasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue Feb 22 20:23:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4966E3A69BF for ; Tue, 22 Feb 2011 20:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.354 X-Spam-Level: X-Spam-Status: No, score=-106.354 tagged_above=-999 required=5 tests=[AWL=1.508, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouKDzOlb8CCq for ; Tue, 22 Feb 2011 20:23:48 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 214313A69B8 for ; Tue, 22 Feb 2011 20:23:48 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.114549063; Tue, 22 Feb 2011 23:24:29 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Tue, 22 Feb 2011 23:24:29 -0500 From: "Livingood, Jason" To: Thomas Narten , Joel Jaeggli Thread-Topic: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 Thread-Index: AQHL0xGPm5VBTLf1nUe00nRH8M8TJw== Date: Wed, 23 Feb 2011 04:24:28 +0000 Message-ID: In-Reply-To: <201102212203.p1LM35o6015377@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.12] Content-Type: multipart/alternative; boundary="_000_C989ADBC19D06jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 04:23:50 -0000 --_000_C989ADBC19D06jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for your review and the feedback below. As noted in the other v6ops = responses today, the changes you suggest will soon be reflected in a =9603 = update. Specific responses to the issues you identified are listed below. Thank you, Jason On 2/21/11 5:03 PM, "Thomas Narten" > wrote: OK. I did a quick read through of the document and think it's mostly fine. [JL] Cool =96 good to hear. Two questions/issues. First, I must have missed the text pointing out that whitelisting is only a heuristic, in that it assumes that the address of query identifies that actual requestor of the DNS info who will ultimately initiate the v6 communication. In fact, the actual network address of the client making the query may be unrelated to the DNS recursive resolvers address, and thus the whitelisting policy a the server may get this wrong. (This is certainly one of the complaints people have raised.) Where is this covered? I assume it is, and I admit to having missed it, so I wonder if the point is being made a little too subtly. :-) [JL] Well, perhaps so subtly that it was missed! ;-) Thanks for pointing th= is out. I am planning to add this brief text at the end of Section 4 (Conce= rns Regarding DNS Whitelisting) as noted below. Let me know if you think th= is text should be modified of course. An additional concern is that the IP address of a recursive resolver is not= a precise indicator of the IPv6 preparedness, or lack of IPv6-related impa= irments, of end user hosts which query (use) a particular recursive resolve= r. While the recursive resolver may be an imperfect proxy for judging IPv6 = preparedness, it is at least one of the best available methods at the curre= nt time. Second, is the DNSSEC section really this simple? 10.1. DNSSEC Considerations DNS security extensions defined in [RFC4033], [RFC4034], and [RFC4035] use cryptographic digital signatures to provide origin authentication and integrity assurance for DNS data. This is done by creating signatures for DNS data on a Security-Aware Authoritative Name Server that can be used by Security-Aware Resolvers to verify the answers. Since DNS whitelisting is implemented on an authoritative server, which provides different answers depending upon which resolver server has sent a query, the DNSSEC chain of trust is not altered. Therefore there are no DNSSEC implications per se. However, any implementer of DNS whitelisting should be quite careful if they implement both DNSSEC signing of their domain and also DNS whitelisting of that same domain. Specifically, those domains should ensure that records are being appropriately and reliably signed, which may well prove operationally and/or technically challenging. This basically says you can make this work just fine with DNSSEC. Is that so? Has this feature been implemented/deployed? I.e., do we have real experience with this? Do DNSSEC folk agree with the above text? [JL] I'm not aware that anyone has put this into practice as of yet, but pe= ople with the relevant expertise have indicated it should work fine (this w= ill of course get an even closer review during both IESG review and a secur= ity review, which typically follow WGLC). Basically, the authoritative serv= er is handling the responses from recursive servers. Since the authoritativ= e server is therefore the control point, it can sign both A and AAAA RRs, a= nd it is just that the AAAAs are not always handed out. So this should be o= kay from the perspective of a chain-of-trust (in contrast to if a recursive= resolver attempted to say block or rewrite AAAA RR responses in a signed d= omain). However, this made me think that I have a related item in Section 3 that I = modified as follows (see underlined text): These end user networks may also have other tools at their disposal in orde= r to address this concern, including applying rules to network equipment su= ch as routers and firewalls (this will necessarily vary by the type of netw= ork, as well as the technologies used and the design of a given network), a= s well as configuration of their recursive resolvers (though modifying or s= uppressing AAAA resource records in a DNSSEC-signed domain on a Security-Aw= are Resolver will be problematic [reference to DNSSEC section]). In any case, based on my last email to Tina Tsou, here's the latest text fo= r that section. I've now added a second paragraph to this, based on the new= text above in Section 3. Don't hesitate to suggest modifications of course= to any of this section. DNS security extensions defined in [RFC4033], [RFC4034], and [RFC4035] use cryptographic digital signatures to provid= e origin authentication and integrity assurance for DNS data. This is done = by creating signatures for DNS data on a Security-Aware Authoritative Name = Server that can be used by Security-Aware Resolvers to verify the answers. = Since DNS whitelisting is implemented on an authoritative server, which pro= vides different answers depending upon which resolver server has sent a que= ry, the DNSSEC chain of trust is not altered. Even though the authoritative= server will not always return a AAAA resource record when one exists, resp= ective A resource records and AAAA resource records can and should both be = signed. Therefore there are no DNSSEC implications per se. However, any im= plementer of DNS whitelisting should be careful if they implement both DNSS= EC signing of their domain and also DNS whitelisting of that same domain. S= pecifically, those domains should ensure that resource records are being ap= propriately and reliably signed, which may present incremental operational = and/or technical challenges. However, as noted in [Section 3], end user networks may also choose to impl= ement tools at their disposal in order to address IPv6-related impairments.= One of those possible tools could involve unspecified changes to the confi= guration of their recursive resolvers. If it is a Security-Aware Resolver, = modifying or suppressing AAAA resource records for a DNSSEC-signed domain w= ill be problematic and could break the chain of trust established with DNSS= EC. Thanks, Jason --_000_C989ADBC19D06jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Thanks for your review and the feedback below. As noted in the other v= 6ops responses today, the changes you suggest will soon be reflected in a = =9603 update. Specific responses to the issues you identified are listed be= low. 

Thank you,
Jason

On 2/21/11 5:03 PM, "Thomas Narten" <narten@us.ibm.com> wrote:

OK. I did a quick read through of the document and think it's mostly
fine.

[JL] Cool =96 good to hear.

Two questions/issues.

First, I must have missed the text pointing out that whitelisting is
only a heuristic, in that it assumes that the address of query
identifies that actual requestor of the DNS info who will ultimately
initiate the v6 communication. In fact, the actual network address of<= /div>
the client making the query may be unrelated to the DNS recursive
resolvers address, and thus the whitelisting policy a the server may
get this wrong. (This is certainly one of the complaints people have
raised.)

Where is this covered? I assume it is, and I admit to having missed
it, so I wonder if the point is being made a little too subtly. :-)

[JL] Well, perhaps so subtly that it was missed! ;-) Thanks for pointi= ng this out. I am planning to add this brief text at the end of Section 4 (= Concerns Regarding DNS Whitelisting) as noted below. Let me know if you thi= nk this text should be modified of course.

An additional concern is that the IP address of a recursive resolve= r is not a precise indicator of the IPv6 preparedness, or lack of IPv6-rela= ted impairments, of end user hosts which query (use) a particular recursive= resolver. While the recursive resolver may be an imperfect proxy for judging IPv6 preparedness, it is at least on= e of the best available methods at the current time.

Second, is the DNSSEC section really this simple?

    10.1.  DNSSEC Considerations
    DNS security extensions defined in [RFC4033], = [RFC4034], and
    [RFC4035] use cryptographic digital signatures= to provide origin
    authentication and integrity assurance for DNS= data.  This is done by
    creating signatures for DNS data on a Security= -Aware Authoritative
    Name Server that can be used by Security-Aware= Resolvers to verify
    the answers.  Since DNS whitelisting= is implemented on an
    authoritative server, which provides different= answers depending upon
    which resolver server has sent a query, the DN= SSEC chain of trust is
    not altered.  Therefore there are no= DNSSEC implications per se.
    However, any implementer of DNS whitelisting s= hould be quite careful
    if they implement both DNSSEC signing of their= domain and also DNS
    whitelisting of that same domain.  S= pecifically, those domains should
    ensure that records are being appropriately an= d reliably signed,
    which may well prove operationally and/or tech= nically challenging.

This basically says you can make this work just fine with DNSSEC. Is
that so? Has this feature been implemented/deployed? I.e., do we have<= /div>
real experience with this? Do DNSSEC folk agree with the above text?

[JL] I'm not aware that anyone has put this into practice as of yet, b= ut people with the relevant expertise have indicated it should work fine (t= his will of course get an even closer review during both IESG review and a = security review, which typically follow WGLC). Basically, the authoritative server is handling the response= s from recursive servers. Since the authoritative server is therefore the c= ontrol point, it can sign both A and AAAA RRs, and it is just that the AAAA= s are not always handed out. So this should be okay from the perspective of a chain-of-trust (in contrast = to if a recursive resolver attempted to say block or rewrite AAAA RR respon= ses in a signed domain). 

However, this made me think that I have a related item in Section 3 th= at I modified as follows (see underlined text): 

These end user networ= ks may also have other tools at their disposal in order to address this con= cern, including applying rules to network equipment such as routers and fir= ewalls (this will necessarily vary by the type of network, as well as the technologies used and the design of= a given network), as well as configuration of their recursive resolvers (though modifying or suppressing AAAA resource records in a DNSSEC-signe= d domain on a Security-Aware Resolver will be problematic [reference to DNS= SEC section]).


In any case, based on my last email to Tina Tsou, here's the latest te= xt for that section. I've now added a second paragraph to this, based on th= e new text above in Section 3. Don't hesitate to suggest modifications of c= ourse to any of this section.

DNS security exten= sions defined in [RFC4033], [RFC4034= ], and [RFC4035] use cryptographic digital signatures to provide origin authentication and inte= grity assurance for DNS data. This is done by creating signatures for DNS d= ata on a Security-Aware Authoritative Name Server that can be used by Secur= ity-Aware Resolvers to verify the answers. Since DNS whitelisting is implemented on an au= thoritative server, which provides different answers depending upon which r= esolver server has sent a query, the DNSSEC chain of trust is not altered. = Even though the authoritative server will not always return a AAAA resource record when one exists, respective = A resource records and AAAA resource records can and should both be signed.=  Therefore there are no DNSSEC implications per se. However, any impl= ementer of DNS whitelisting should be careful if they implement both DNSSEC signing of their domain and also DNS= whitelisting of that same domain. Specifically, those domains should ensur= e that resource records are being appropriately and reliably signed, which = may present incremental operational and/or technical challenges.

However, as noted in [Section 3], end user networks may also choose= to implement tools at their disposal in order to address IPv6-related impa= irments. One of those possible tools could involve unspecified changes to t= he configuration of their recursive resolvers. If it is a Security-Aware Resolver, modifying or suppressing AA= AA resource records for a DNSSEC-signed domain will be problematic and coul= d break the chain of trust established with DNSSEC.


Thanks,
Jason

--_000_C989ADBC19D06jasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue Feb 22 20:24:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7A7C3A69D1 for ; Tue, 22 Feb 2011 20:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.353 X-Spam-Level: X-Spam-Status: No, score=-103.353 tagged_above=-999 required=5 tests=[AWL=-1.619, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqJPoIliCIT6 for ; Tue, 22 Feb 2011 20:24:19 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 14C973A69B6 for ; Tue, 22 Feb 2011 20:24:19 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.26964275; Tue, 22 Feb 2011 21:36:02 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Tue, 22 Feb 2011 23:24:26 -0500 From: "Livingood, Jason" To: Tina Tsou Thread-Topic: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 Thread-Index: AQHL0hJMiSnmnTOq9kOktdj8dZOxy5QMg5dQgAGk4gA= Date: Wed, 23 Feb 2011 04:24:24 +0000 Message-ID: In-Reply-To: <026f01cbd214$a1b71420$e5253c60$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.12] Content-Type: multipart/alternative; boundary="_000_C989A97819CE3jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 04:24:21 -0000 --_000_C989A97819CE3jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Tina =96 Thank you for your review and specific feedback below. These ch= anges will be in the =9603 update soon. See my specific responses inline be= low. Thanks! Jason On 2/21/11 5:13 PM, "Tina Tsou" > w= rote: Hi, I generally support this document as attempt on real operational issues inv= olved in the deployment of IPv6. [JL] Thanks! :-) Comments on section 10.1 =93DNSSEC Considerations=94 are below. It says that different answers are sent to different querying hosts. If tho= se are all known in advance, and the server has the DNS zone signing key, i= t can separately sign the various alternative answer data sets however you = want. If they are not known in advance, then you have to have the keys on-l= ine so you can sign answer data in real time=85 [JL] Good point. I have attempted to make this more clear. Here is how that= section now appears. If you think this needs further modification, just sa= y so. DNS security extensions defined in [RFC4033], [RFC4034], and [RFC4035] use = cryptographic digital signatures to provide origin authentication and integ= rity assurance for DNS data. This is done by creating signatures for DNS da= ta on a Security-Aware Authoritative Name Server that can be used by Securi= ty-Aware Resolvers to verify the answers. Since DNS whitelisting is impleme= nted on an authoritative server, which provides different answers depending= upon which resolver server has sent a query, the DNSSEC chain of trust is = not altered. Even though the authoritative server will not always return a = AAAA resource record when one exists, respective A resource records and AAA= A resource records can and should both be signed. Therefore there are no D= NSSEC implications per se. However, any implementer of DNS whitelisting sho= uld be careful if they implement both DNSSEC signing of their domain and al= so DNS whitelisting of that same domain. Specifically, those domains should= ensure that resource records are being appropriately and reliably signed, = which may present incremental operational and/or technical challenges. Thank you again, Jason We keep our promises with one another =96 no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Livingood, Jason Sent: Monday, February 21, 2011 1:57 PM To: Joel Jaeggli; Doug Barton Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implication= s-02 I proposed a series of edits (sent to jason first due to their length) that neutralize the tone a bit but without I think altering the content. I think that the characterization of the problems with a whitelisting approach is useful and important. It's going to (has) happened anyway and it's not a "we told you so" it's "these are the issues you have to contend with." [JL] I am mid-way through those edits (will take another day or so to facto= r them all in). These suggestions will be adopted in a =9603 version along = with the other specific feedback received in the past few days of WGLC. Regards Jason --_000_C989A97819CE3jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <077F19CE5B4F2E4BAF388DC831BD8CB8@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Hi Tina =96 Thank you for your review and specific feedback below. The= se changes will be in the =9603 update soon. See my specific responses inli= ne below.

Thanks!
Jason

On 2/21/11 5:13 PM, "Tina Tsou" <tena@huawei.com> wrote:

Hi,

I generally support this document = as attempt on real operational issues involved in the deployment of IPv6.

[JL] Thanks! :-)

Comment= s on section 10.1 =93DNSSEC Considerations=94 are below.

It says that different answers are= sent to different querying hosts. If those are all known in advance, and t= he server has the DNS zone signing key, it can separately sign the various alternative answer data sets however yo= u want. If they are not known in advance, then you have to have the keys on= -line so you can sign answer data in real time=85

[JL] Good point. I have attempted to make this more clear. Here is how= that section now appears. If you think this needs further modification, ju= st say so.

DNS security exten= sions defined in [RFC4033]= , [RFC4034], and [RFC4035] use cr= yptographic digital signatures to provide origin authentication and integrity assurance for DNS data. This is done by creat= ing signatures for DNS data on a Security-Aware Authoritative Name Server t= hat can be used by Security-Aware Resolvers to verify the answers. Since DNS whitelisting is implemented on an authoritative server, which provides different answers d= epending upon which resolver server has sent a query, the DNSSEC chain of t= rust is not altered. Even though the authoritative server will not always r= eturn a AAAA resource record when one exists, respective A resource records and AAAA resource records can an= d should both be signed.  Therefore there are no DNSSEC implications p= er se. However, any implementer of DNS whitelisting should be careful if th= ey implement both DNSSEC signing of their domain and also DNS whitelisting of that same domain. Specifically, those = domains should ensure that resource records are being appropriately and rel= iably signed, which may present incremental operational and/or technical ch= allenges.


Thank you again, 
Jason

 

 

We keep our promises with one anot= her =96 no matter what!

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Livingood, Jason
Sent: Monday, February 21, 2011 1:57 PM
To: Joel Jaeggli; Doug Barton
Cc: IPv6 Ops WG
Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-impl= ications-02

 


I proposed a series of edits (sent to jason first due to their length)=

that neutralize the tone a bit but without I think altering th= e content.

I think that the characterization of the problems with a white= listing

approach is useful and important. It's going to (has) happened= anyway

and it's not a "we told you so" it's "these are= the issues you have to

contend with."

 

[JL] I am mid-way through those edits (will take another day o= r so to factor them all in). These suggestions will be adopted in a =9603 v= ersion along with the other specific feedback received in the past few days of WGLC.

 

Regards

Jason

 --_000_C989A97819CE3jasonlivingoodcablecomcastcom_-- From Internet-Drafts@ietf.org Tue Feb 22 21:00:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187323A69F4; Tue, 22 Feb 2011 21:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i25mZDS5inbQ; Tue, 22 Feb 2011 21:00:07 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3553A69EE; Tue, 22 Feb 2011 21:00:07 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110223050007.28194.90637.idtracker@localhost> Date: Tue, 22 Feb 2011 21:00:07 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 05:00:10 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 AAAA DNS Whitelisting Implications Author(s) : J. Livingood Filename : draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt Pages : 32 Date : 2011-02-22 The objective of this document is to describe what the whitelisting of DNS AAAA resource records is, hereafter referred to as DNS whitelisting, as well as the implications of this emerging practice and what alternatives may exist. The audience for this document is the Internet community generally, including the IETF and IPv6 implementers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-22204648.I-D@ietf.org> --NextPart-- From cb.list6@gmail.com Tue Feb 22 21:29:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7C03A69FA for ; Tue, 22 Feb 2011 21:29:48 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfDTHnwCzKmi for ; Tue, 22 Feb 2011 21:29:48 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id CEC383A69F8 for ; Tue, 22 Feb 2011 21:29:47 -0800 (PST) Received: by qyk7 with SMTP id 7so3355683qyk.10 for ; Tue, 22 Feb 2011 21:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h/GOnoJN8P0j22O1xvlOIGECRzTVc9AS1LHWmcqrRN4=; b=bK82klaXN+vXAKEWxbX3cd428sDnn6GSaKLGvBWLTtnjTTGFcMJsdREd6bpsJ8+uiR 8FNkPXQ0nF/RfySqqHnNbI5AR0uoxzhNOKccsmy35ID7xy6CkTg5b+o7TqNirNLbFJ6K j/HTiq5eeLHCablygN7gBDx++IpG/moUwvM1E= 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=Lkz71t4aA9WsePfd1fjUVeiy3HS6wYqhvzkzIP44kaUvSUOZcQuK6lPbcnuYZodG/j EaHHg8ZQDdliC8d2wvjKyB9hocPggmrELlelBRGA+bdnT7kjaIfzsvvrL2L3KFws60Ax 5BQvXNsXFbolLrfz9JgpNJLD0OS5YTpWw2RCo= MIME-Version: 1.0 Received: by 10.229.225.199 with SMTP id it7mr40725qcb.7.1298439032168; Tue, 22 Feb 2011 21:30:32 -0800 (PST) Received: by 10.229.185.196 with HTTP; Tue, 22 Feb 2011 21:30:32 -0800 (PST) In-Reply-To: References: <026f01cbd214$a1b71420$e5253c60$@com> Date: Tue, 22 Feb 2011 21:30:32 -0800 Message-ID: From: Cameron Byrne To: "Livingood, Jason" Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 05:29:49 -0000 While this is a different type of white-listing, is it relevant to include a brief discussion of the so-called "yahoo dns hack" www.ietf.org/proceedings/77/slides/dnsop-7.pdf ? I am not sure if it is documented in any other place as an IETF draft or not, but it is implemented today in multiple types of DNS server software. This is a unique case from the rest of the white-listing doc, so it may be out of scope, but i think it is in the same solution space, but different angle, and may impact on how white-listing from the authoritative servers works given that the authoritative policies will be more willing if their is IPv6 workign from end to end (client-recursive-authoritative). If i understand it correctly, this is an action on the recursive name server, not that authoritative name server. I believe it is a relevant tool, especial in a world of hobbled 6to4 and bogon address space. The broken customer calls will come into the ISPs help desk, and this may be a relevant tool to make IPv6 customers happy and keep IPv4 customers working without spending hours troubleshooting the customer LAN. If you think this is out of scope and confuses the issue, i understand. But perhaps including it will make it clear the different between recursive namer server white listing vs authoritative name server white-listing Cameron From jfesler@yahoo-inc.com Tue Feb 22 23:57:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B46853A677C for ; Tue, 22 Feb 2011 23:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.831 X-Spam-Level: X-Spam-Status: No, score=-16.831 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bND+AQZ53BLx for ; Tue, 22 Feb 2011 23:57:02 -0800 (PST) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id AF90F3A67DB for ; Tue, 22 Feb 2011 23:57:02 -0800 (PST) Received: from SP1-EX07CAS02.ds.corp.yahoo.com (sp1-ex07cas02.ds.corp.yahoo.com [216.252.116.138]) by mrout2-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p1N7vKdg060635; Tue, 22 Feb 2011 23:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1298447840; bh=R5SP5eWbFCr+1YUs44HL37BpJBk2nDRWEmXaJ/OVL80=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=f8O2LigbPIaG72g7HAqfMR2SIqSX9VZkrbbE5vhBnvcNijOKaDNYkqq8eIVcP3KV3 jDESfj6hQmVWHuI1IU7YbF/lG070zNIlrCethWymwecRYHy+7hLGeR+0yaIk1RjjAy 8oTpMYem6VS5GQVSZN/10RPjYHgbtG6T/Q9BaZPk= Received: from SP1-EX07VS01.ds.corp.yahoo.com ([216.252.116.139]) by SP1-EX07CAS02.ds.corp.yahoo.com ([216.252.116.167]) with mapi; Tue, 22 Feb 2011 23:57:20 -0800 From: Jason Fesler To: Cameron Byrne Date: Tue, 22 Feb 2011 23:57:19 -0800 Thread-Topic: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 Thread-Index: AcvTL0umwA5U76EdT9SijVxz0w20eA== Message-ID: <44CF409A-E2A6-4AD4-B7B0-92CD786A3718@yahoo-inc.com> References: <026f01cbd214$a1b71420$e5253c60$@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: IPv6 Ops WG , "Livingood, Jason" Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 07:57:03 -0000 On Feb 22, 2011, at 9:30 PM, Cameron Byrne wrote: > While this is a different type of white-listing, is it relevant to > include a brief discussion of the so-called "yahoo dns hack" > www.ietf.org/proceedings/77/slides/dnsop-7.pdf ? FWIW: When we originally discussed that (in a small group) it was believed = that at least one carrier could influence their IPv6 capable users to query= the DNS resolvers over IPv6. The number of ISPs that can do that (today) = I suspect are limited; so the original framing of this proposal should be d= eemphasized. That said, the feature set that we sponsored in bind *does* allow for an ea= sy way for a single recursor to offer A+AAAA to one pool, and A only (when = both would otherwise exist) to your second pool. That alone can be used to= help mitigate the so called "broken user problem", and allow that particul= ar recursor to score well with automated whitelisting systems. So, there i= s value with the system; just not necessarily as directly as we had hoped. Your other points, imo, are quite valid - but I must admit a bias. From cb.list6@gmail.com Wed Feb 23 00:08:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2763A680E for ; Wed, 23 Feb 2011 00:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlS8wAA-WTtQ for ; Wed, 23 Feb 2011 00:08:24 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 012C33A69EE for ; Wed, 23 Feb 2011 00:08:23 -0800 (PST) Received: by qyk29 with SMTP id 29so2718105qyk.10 for ; Wed, 23 Feb 2011 00:09:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FWbsuiz8wsB/0WdSKgoq6+hHqMd8zpnen3ugiMnYlZw=; b=iLtplcBFbzL7SVWMri+ySzByLikNzdg/WGhi1TPUv81sACJlMomNmgskJBOXYNm0qm BLiIFDdIhxVH45qzZ6qmiRcq0hwSelauc3jsa79Rdh68/IeiUiLUyVAh6vLCM8/0jyhE JXiKppu+ftFpET3mhVhxiLmJlajSzcFUg/W6I= 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=F7cSIskj9ehR9ZrHfwINFTzWT3rZy9rLdGEKH/P5cSoeF3DqkkSVo1gjUvABUlMTnU uOOY+K1O549wbSmKwbpLc+86SOb4S6x0QsmZpERt+rdE5SLi/Jh5HiPodom38ZvKG+so JAcDcjtcqqKlh0Nk/liOT0a7x778X8qCmRmMU= MIME-Version: 1.0 Received: by 10.224.6.129 with SMTP id 1mr3086047qaz.251.1298448550132; Wed, 23 Feb 2011 00:09:10 -0800 (PST) Received: by 10.229.185.196 with HTTP; Wed, 23 Feb 2011 00:09:10 -0800 (PST) Received: by 10.229.185.196 with HTTP; Wed, 23 Feb 2011 00:09:10 -0800 (PST) In-Reply-To: <44CF409A-E2A6-4AD4-B7B0-92CD786A3718@yahoo-inc.com> References: <026f01cbd214$a1b71420$e5253c60$@com> <44CF409A-E2A6-4AD4-B7B0-92CD786A3718@yahoo-inc.com> Date: Wed, 23 Feb 2011 00:09:10 -0800 Message-ID: From: Cameron Byrne To: Jason Fesler Content-Type: multipart/alternative; boundary=0015175cb58096fd02049cee9cd2 Cc: IPv6 Ops WG , "Livingood, Jason" Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 08:08:25 -0000 --0015175cb58096fd02049cee9cd2 Content-Type: text/plain; charset=ISO-8859-1 On Feb 22, 2011 11:57 PM, "Jason Fesler" wrote: > > > On Feb 22, 2011, at 9:30 PM, Cameron Byrne wrote: > > > While this is a different type of white-listing, is it relevant to > > include a brief discussion of the so-called "yahoo dns hack" > > www.ietf.org/proceedings/77/slides/dnsop-7.pdf ? > > FWIW: When we originally discussed that (in a small group) it was believed that at least one carrier could influence their IPv6 capable users to query the DNS resolvers over IPv6. The number of ISPs that can do that (today) I suspect are limited; so the original framing of this proposal should be deemphasized. > It applies very well to mobile Cb > That said, the feature set that we sponsored in bind *does* allow for an easy way for a single recursor to offer A+AAAA to one pool, and A only (when both would otherwise exist) to your second pool. That alone can be used to help mitigate the so called "broken user problem", and allow that particular recursor to score well with automated whitelisting systems. So, there is value with the system; just not necessarily as directly as we had hoped. > > Your other points, imo, are quite valid - but I must admit a bias. > > --0015175cb58096fd02049cee9cd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Feb 22, 2011 11:57 PM, "Jason Fesler" <jfesler@yahoo-inc.com> wrote:
>
>
> On Feb 22, 2011, at 9:30 PM, Cameron Byrne wrote:
>
> > While this is a different type of white-listing, is it relevant t= o
> > include a brief discussion of the so-called "yahoo dns hack&= quot;
> > www.ietf.org/proceedings/77/slides/dnsop-7.pdf ?
>
> FWIW: When we originally discussed that (in a small group) it was beli= eved that at least one carrier could influence their IPv6 capable users to = query the DNS resolvers over IPv6. =A0The number of ISPs that can do that (= today) I suspect are limited; so the original framing of this proposal shou= ld be deemphasized.
>

It applies very well to mobile

Cb

> That said, the feature set that we sponsored in bind *does* allow f= or an easy way for a single recursor to offer A+AAAA to one pool, and A onl= y (when both would otherwise exist) to your second pool. =A0That alone can = be used to help mitigate the so called "broken user problem", and= allow that particular recursor to score well with automated whitelisting s= ystems. =A0So, there is value with the system; just not necessarily as dire= ctly as we had hoped.
>
> Your other points, imo, are quite valid - but I must admit a bias.
>
>

--0015175cb58096fd02049cee9cd2-- From jason_livingood@cable.comcast.com Wed Feb 23 06:47:13 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9D03A6A26 for ; Wed, 23 Feb 2011 06:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.288 X-Spam-Level: X-Spam-Status: No, score=-103.288 tagged_above=-999 required=5 tests=[AWL=-1.554, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGwSN3FQ33te for ; Wed, 23 Feb 2011 06:47:12 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 940DD3A6A21 for ; Wed, 23 Feb 2011 06:47:12 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.26998600; Wed, 23 Feb 2011 07:59:32 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Wed, 23 Feb 2011 09:47:43 -0500 From: "Livingood, Jason" To: Cameron Byrne Thread-Topic: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 Thread-Index: AQHL0hJMiSnmnTOq9kOktdj8dZOxy5QMg5dQgAGk4gCAALzHAIAAR9gA Date: Wed, 23 Feb 2011 14:47:42 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.14] Content-Type: multipart/alternative; boundary="_000_C98A87E919EE3jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 14:47:13 -0000 --_000_C98A87E919EE3jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see Jason Fesler replied on the substance of most of your questions. For = the purposes of this document, I'd like to keep it out of scope though. It = certainly may be worth a separate I-D from someone else, but it may be a DN= SEXT WG draft (TBD). JL On 2/23/11 12:30 AM, "Cameron Byrne" > wrote: While this is a different type of white-listing, is it relevant to include a brief discussion of the so-called "yahoo dns hack" www.ietf.org/proceedings/77/slides/dnsop-7.pdf ? I am not sure if it is documented in any other place as an IETF draft or not, but it is implemented today in multiple types of DNS server software. This is a unique case from the rest of the white-listing doc, so it may be out of scope, but i think it is in the same solution space, but different angle, and may impact on how white-listing from the authoritative servers works given that the authoritative policies will be more willing if their is IPv6 workign from end to end (client-recursive-authoritative). If i understand it correctly, this is an action on the recursive name server, not that authoritative name server. I believe it is a relevant tool, especial in a world of hobbled 6to4 and bogon address space. The broken customer calls will come into the ISPs help desk, and this may be a relevant tool to make IPv6 customers happy and keep IPv4 customers working without spending hours troubleshooting the customer LAN. If you think this is out of scope and confuses the issue, i understand. But perhaps including it will make it clear the different between recursive namer server white listing vs authoritative name server white-listing Cameron --_000_C98A87E919EE3jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1145E46CA12A5245968DCA94C622AE74@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
I see Jason Fesler replied on the substance of most of your questions.= For the purposes of this document, I'd like to keep it out of scope though= . It certainly may be worth a separate I-D from someone else, but it may be= a DNSEXT WG draft (TBD).

JL


On 2/23/11 12:30 AM, "Cameron Byrne" <cb.list6@gmail.com> wrote:

While this is a different type of white-listing, is it relevant to
include a brief discussion of the so-called "yahoo dns hack"=
www.ietf.org/proceedings/77/slides/dnsop-7.pdf ?  I am not s= ure if it
is documented in any other place as an IETF draft or not, but it is
implemented today in multiple types of DNS server software.

This is a unique case from the rest of the white-listing doc, so it
may be out of scope, but i think it is in the same solution space, but=
different angle, and may impact on how white-listing from the
authoritative servers works given that the authoritative policies will=
be more willing if their is IPv6 workign from end to end
(client-recursive-authoritative).

If i understand it correctly, this is an action on the recursive name<= /div>
server, not that authoritative name server.  I believe it is= a
relevant tool, especial in a world of hobbled 6to4 and bogon address
space.  The broken customer calls will come into the ISPs he= lp desk,
and this may be a relevant tool to make IPv6 customers happy and keep<= /div>
IPv4 customers working without spending hours troubleshooting the
customer LAN.

If you think this is out of scope and confuses the issue, i
understand.  But perhaps including it will make it clear the= different
between recursive namer server white listing vs authoritative name
server white-listing

Cameron

--_000_C98A87E919EE3jasonlivingoodcablecomcastcom_-- From dougb@dougbarton.us Wed Feb 23 12:27:35 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED183A6877 for ; Wed, 23 Feb 2011 12:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+GmzmFtUmub for ; Wed, 23 Feb 2011 12:27:34 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id A2ED03A67D2 for ; Wed, 23 Feb 2011 12:27:34 -0800 (PST) Received: (qmail 4180 invoked by uid 399); 23 Feb 2011 20:28:19 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 23 Feb 2011 20:28:19 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D656DE2.8090903@dougbarton.us> Date: Wed, 23 Feb 2011 12:28:18 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Livingood, Jason" References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 20:27:35 -0000 On 02/22/2011 06:57, Livingood, Jason wrote: > [JL] To give one perspective, that of a network operator, please see > Section 7.3.1, 7.3.3, 7.3.4, and 7.3.6. A network operator needs > to add > staff to discover which domains whitelist, discover the policies and > application process for each domain, apply to be whitelisted for > each > domain, and monitor progress / approvals / appeals. Then, once it is > place, monitoring must be put in place to ensure whitelisting > remains in > place and there is manual intervention via NOC and IPv6 SMEs when > de-whitelisting occurs (through error or for some other reason). In > addition, let's not leave off the added complexity of > troubleshooting > end user problems (we measure this in incremental > seconds/minutes on the > phone with users). > > > Ok, I'll grant you all of those, but I will also point out that all of > those costs are voluntary. > > > [JL] They are optional for the domain doing the whitelisting, but not > really for others (such as network operators). Sure, in theory it is > optional, but it will not long satisfy some users that they cannot > access content X or Y via IPv6. So the cost burden is voluntary for the > whitelisted domain and involuntary for others IMHO. I think you misunderstood me on "optional." I meant that the costs are optional for those networks _applying_ to be whitelisted, but there is an even more serious disconnect apparent in what you wrote above. In my first post about this draft I pointed out that I think most of Section 4 is pointless because no one is going to be deploying v6-only hosts any time soon. Obviously I need to amplify my point. NO ONE IS GOING TO BE .... just kidding. :) But seriously folks, while we still live in a mostly-v4 world there are simply not going to be content providers putting up v6-only hosts. It will be years from now before that happens, and when it happens it will be (in large part) _because_ the issues that whitelisting is designed to avoid are no longer a problem. So you're completely on the wrong side of the chicken-egg problem to start with. But this is also an excellent example of why I think people are likely to find this draft offensive rather than helpful. Do you(pl.) honestly believe that operators are so incredibly stupid that the need to have it explained to them that, "If you put up a v6-only host, and then do whitelisting, some people with v6 transport won't be able to reach it." And if you _do_ believe that it's necessary to explain that, can you explain to me why you believe it? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From wwwrun@rfc-editor.org Wed Feb 23 16:59:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10D83A6960; Wed, 23 Feb 2011 16:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKKA27eSgn4y; Wed, 23 Feb 2011 16:59:01 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id D33933A691B; Wed, 23 Feb 2011 16:59:01 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6C4FEE06EE; Wed, 23 Feb 2011 16:59:50 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110224005950.6C4FEE06EE@rfc-editor.org> Date: Wed, 23 Feb 2011 16:59:50 -0800 (PST) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6104 on Rogue IPv6 Router Advertisement Problem Statement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 00:59:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6104 Title: Rogue IPv6 Router Advertisement Problem Statement Author: T. Chown, S. Venaas Status: Informational Stream: IETF Date: February 2011 Mailbox: tjc@ecs.soton.ac.uk, stig@cisco.com Pages: 16 Characters: 36518 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-rogue-ra-02.txt URL: http://www.rfc-editor.org/rfc/rfc6104.txt When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements (RAs) to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the RA message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed. 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 wwwrun@rfc-editor.org Wed Feb 23 16:59:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9F043A6A07; Wed, 23 Feb 2011 16:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ari8VybxdME2; Wed, 23 Feb 2011 16:59:15 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id EAFDE3A6960; Wed, 23 Feb 2011 16:59:14 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 43A20E073A; Wed, 23 Feb 2011 17:00:03 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110224010003.43A20E073A@rfc-editor.org> Date: Wed, 23 Feb 2011 17:00:03 -0800 (PST) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6105 on IPv6 Router Advertisement Guard X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 00:59:15 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6105 Title: IPv6 Router Advertisement Guard Author: E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. Mohacsi Status: Informational Stream: IETF Date: February 2011 Mailbox: elevyabe@cisco.com, gunter@cisco.com, chip@technodyne.com, mohacsi@niif.hu Pages: 10 Characters: 20817 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ra-guard-08.txt URL: http://www.rfc-editor.org/rfc/rfc6105.txt Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. 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 hu.yuxing@zte.com.cn Wed Feb 23 19:14:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B60D3A67E4 for ; Wed, 23 Feb 2011 19:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.035 X-Spam-Level: X-Spam-Status: No, score=-97.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFBWNLFP0ijw for ; Wed, 23 Feb 2011 19:14:10 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id CD0A93A67C2 for ; Wed, 23 Feb 2011 19:14:09 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 3510102519342; Thu, 24 Feb 2011 11:12:14 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 23516.102519342; Thu, 24 Feb 2011 11:05:57 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p1O3EhkX049523 for ; Thu, 24 Feb 2011 11:14:43 +0800 (GMT-8) (envelope-from hu.yuxing@zte.com.cn) To: v6ops@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: hu.yuxing@zte.com.cn Date: Thu, 24 Feb 2011 11:14:34 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-24 11:14:44, Serialize complete at 2011-02-24 11:14:44 Content-Type: multipart/alternative; boundary="=_alternative 00122CC048257841_=" X-MAIL: mse02.zte.com.cn p1O3EhkX049523 Subject: [v6ops] FW: New Version Notification for draft-hu-dhc-dhcpv6-for-dual-stack-hosts-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 03:14:11 -0000 This is a multipart message in MIME format. --=_alternative 00122CC048257841_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SUVURiBJLUQgU3VibWlzc2lvbiBUb29sIDxpZHN1Ym1pc3Npb25AaWV0Zi5vcmc+IA0KMjAxMS0w Mi0yMyAxNzozMA0KDQrK1bz+yMsNCmh1Lnl1eGluZ0B6dGUuY29tLmNuDQqzrcvNDQoNCtb3zOIN Ck5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHUtZGhjLWRoY3B2Ni1mb3ItZHVh bC1zdGFjay1ob3N0cy0wMA0KDQoNCg0KDQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtaHUtZGhjLWRoY3B2Ni1mb3ItZHVhbC1zdGFjay1ob3N0cy0wMC50eHQgaGFzIA0KYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFl1eGluZyBIdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG IA0KcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICAgICAgICAgICBkcmFmdC1odS1kaGMt ZGhjcHY2LWZvci1kdWFsLXN0YWNrLWhvc3RzDQpSZXZpc2lvbjogICAgICAgICAgICAgICAgIDAw DQpUaXRsZTogICAgICAgICAgICAgICAgICAgICAgICAgICAgREhDUFY2IGZvciBkdWFsLXN0YWNr IGhvc3RzDQpDcmVhdGlvbl9kYXRlOiAgICAgICAgICAgIDIwMTEtMDItMjINCldHIElEOiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBJbmRlcGVuZGVudCBTdWJtaXNzaW9uDQpOdW1iZXJfb2Zf cGFnZXM6IDEyDQoNCkFic3RyYWN0Og0KQSBkdWFsLXN0YWNrIGhvc3QgbWF5IHdpc2ggdG8gb2J0 YWluIElQdjQgYW5kL29yIElQdjYgY29uZmlndXJhdGlvbg0Kc2V0dGluZ3MgdmlhIHRoZSBEeW5h bWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCAoREhDUCkuTmV0d29yaw0Kb3BlcmF0b3Jz IGRlcGxveSBzZXBlcmF0ZSBESENQdjQgc2VydmVycyBhbmQgREhDUHY2IHNlcnZlcnMsaG9zdHMg Z2V0DQpJUHY0IHBhcmFtZXRlcnMgdmlhIERIQ1B2NCBzZXJ2ZXJzIGFuZCBJUHY2IHBhcmFtZXRl cnMgdmlhIERIQ1B2Ng0Kc2VydmVycy4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc29sdXRp b24sdGhlcmUgaXMgb25seSBhIHNpbmdsZQ0KaW50ZXJncmF0ZWQgREhDUHY2IHNlcnZlciBkZXBs b3llZCBpbiB0aGUgSVNQIG5ldHdvcmssaG9zdHMgb2J0YWluDQpib3RoIElQdjQgYW5kIElQdjYg Y29uZmlndXJhdGlvbiBzZXR0aW5ncyBmcm9tIHRoaXMgc2VydmVyLg0KICANCg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdC4NCg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90 aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJv cGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRp b24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQg dG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhl IGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFu ZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo b20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2 aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVh bCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQg U3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 00122CC048257841_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+SUVURiBJLUQgU3VibWlz c2lvbiBUb29sDQombHQ7aWRzdWJtaXNzaW9uQGlldGYub3JnJmd0OzwvYj4gPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDItMjMgMTc6MzA8L2ZvbnQ+DQo8 dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7Iyzwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+aHUueXV4aW5n QHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1odS1kaGMtZGhjcHY2LWZvci1kdWFsLXN0YWNrLWhv c3RzLTAwPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yPjx0dD48YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaHUtZGhjLWRoY3B2Ni1m b3ItZHVhbC1zdGFjay1ob3N0cy0wMC50eHQgaGFzDQpiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgWXV4aW5nIEh1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48YnI+DQo8 YnI+DQpGaWxlbmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ZHJhZnQtaHUtZGhjLWRoY3B2Ni1mb3ItZHVhbC1zdGFjay1o b3N0czxicj4NClJldmlzaW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDswMDxicj4NClRpdGxlOiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KREhDUFY2IGZv ciBkdWFsLXN0YWNrIGhvc3RzPGJyPg0KQ3JlYXRpb25fZGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7MjAxMS0wMi0yMjxi cj4NCldHIElEOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KSW5kZXBlbmRlbnQgU3VibWlzc2lvbjxicj4NCk51bWJlcl9vZl9w YWdlczogMTI8YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQpBIGR1YWwtc3RhY2sgaG9zdCBtYXkg d2lzaCB0byBvYnRhaW4gSVB2NCBhbmQvb3IgSVB2NiBjb25maWd1cmF0aW9uPGJyPg0Kc2V0dGlu Z3MgdmlhIHRoZSBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCAoREhDUCkuTmV0 d29yazxicj4NCm9wZXJhdG9ycyBkZXBsb3kgc2VwZXJhdGUgREhDUHY0IHNlcnZlcnMgYW5kIERI Q1B2NiBzZXJ2ZXJzLGhvc3RzIGdldDxicj4NCklQdjQgcGFyYW1ldGVycyB2aWEgREhDUHY0IHNl cnZlcnMgYW5kIElQdjYgcGFyYW1ldGVycyB2aWEgREhDUHY2PGJyPg0Kc2VydmVycy4gJm5ic3A7 VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBzb2x1dGlvbix0aGVyZSBpcyBvbmx5IGEgc2luZ2xl PGJyPg0KaW50ZXJncmF0ZWQgREhDUHY2IHNlcnZlciBkZXBsb3llZCBpbiB0aGUgSVNQIG5ldHdv cmssaG9zdHMgb2J0YWluPGJyPg0KYm90aCBJUHY0IGFuZCBJUHY2IGNvbmZpZ3VyYXRpb24gc2V0 dGluZ3MgZnJvbSB0aGlzIHNlcnZlci48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCjxicj4NCjxicj4NClRoZSBJ RVRGIFNlY3JldGFyaWF0Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGJy PjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTom bmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhp cyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJz cDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFp bCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNp cGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNw O3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90 Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRl bnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3Ro ZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0 cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZu YnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7 dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkm bmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNw O0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWls Jm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNw O29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7 dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7 YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5k ZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5i c3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZu YnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 00122CC048257841_=-- From brian.e.carpenter@gmail.com Wed Feb 23 20:28:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1BF23A67C1 for ; Wed, 23 Feb 2011 20:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.453 X-Spam-Level: X-Spam-Status: No, score=-103.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-7qcyHU7jgz for ; Wed, 23 Feb 2011 20:28:52 -0800 (PST) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by core3.amsl.com (Postfix) with ESMTP id D8FDE3A67F5 for ; Wed, 23 Feb 2011 20:28:51 -0800 (PST) Received: by gwj22 with SMTP id 22so97940gwj.27 for ; Wed, 23 Feb 2011 20:29:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=IvsS50SzD3vjT9CjuZZghxQDyZ1SpVTBSJ7fSNRkFxg=; b=mtvZfLMZfxYblnc8LoYohubPXT2w45q6VSceij0MMN7rAwyNloj9Z+hXr8TFTpmb8z UEHOSOsPp8niGr3RmT1ow4kmYPSVw5PEbDFshCp4Iz5iqV7Y7PwcJOrkCPyAH2Q9VJIw QRcM9CGhsEiHV7ZXYwGDh53DE09gLnl4M7jeI= 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=M9hQBTYJfUzASRJnyDbFmjTdLkNRcAp0fZ2EVtiaSfSZ+qT5xlFACvVxqvUkCIwBg7 x58XUs8J4OVvmJ6lj2/gqN3Mqj7IdLPBfeX+SYdW67EmqenhVRaUtjVa4cTpA45MkN0I aZJFI1bFJhZPbdv4t7UYf1weF8TyFe1+zOehk= Received: by 10.100.168.5 with SMTP id q5mr177567ane.223.1298521780060; Wed, 23 Feb 2011 20:29:40 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id z12sm3934427anp.19.2011.02.23.20.29.38 (version=SSLv3 cipher=OTHER); Wed, 23 Feb 2011 20:29:39 -0800 (PST) Message-ID: <4D65DEA4.5000200@gmail.com> Date: Thu, 24 Feb 2011 17:29:24 +1300 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=utf-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] [Fwd: New Version Notification for draft-carpenter-v6ops-6to4-teredo-advisory-02] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 04:28:53 -0000 This version has all comments to date incorporated and all mention of Teredo removed. (I decided not to confuse matters by changing the file name). Since there is quite a lot of operator interest in this can we discuss fairly quickly whether to progress it as a WG item? Brian -------- Original Message -------- Subject: New Version Notification for draft-carpenter-v6ops-6to4-teredo-advisory-02 Date: Wed, 23 Feb 2011 20:26:32 -0800 (PST) From: IETF I-D Submission Tool To: brian.e.carpenter@gmail.com A new version of I-D, draft-carpenter-v6ops-6to4-teredo-advisory-02.txt has been successfully submitted by Brian Carpenter and posted to the IETF repository. Filename: draft-carpenter-v6ops-6to4-teredo-advisory Revision: 02 Title: Advisory Guidelines for 6to4 Deployment Creation_date: 2011-02-24 WG ID: Independent Submission Number_of_pages: 18 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. The intention of the advice is to minimise both user dissatisfaction and help desk calls. The IETF Secretariat. -- Regards Brian Carpenter From joelja@bogus.com Wed Feb 23 22:38:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3FA3A63CB for ; Wed, 23 Feb 2011 22:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3IKsMAel5Bz for ; Wed, 23 Feb 2011 22:38:20 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 2D0753A6820 for ; Wed, 23 Feb 2011 22:38:19 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p1O6d4uQ072599 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 24 Feb 2011 06:39:05 GMT (envelope-from joelja@bogus.com) Message-ID: <4D65FD06.9030305@bogus.com> Date: Wed, 23 Feb 2011 22:39:02 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPv6 Ops WG , Ron Bonica , V6ops Chairs References: <4D4F6887.7050203@bogus.com> In-Reply-To: <4D4F6887.7050203@bogus.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Thu, 24 Feb 2011 06:39:07 +0000 (UTC) Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 06:38:23 -0000 Last Call for this document has concluded... Jason did an epic job at turning around both the suggested changes and the minor but relatively numerous language edits suggested. The result is draft-03 here: http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 and the diff1 output here: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt Barring the signficant gnashing of teeth, we will proceed with a document shepherd writeup and request IESG publication. Doug Barton's criticsm will be noted in the document shepherd review which I will circulate probably Monday. if anyone feels like they might be inclined to file an appeal at some later date please let me know so I can inlude that information in the packet for the IESG. thanks. joel On 2/6/11 7:35 PM, Joel Jaeggli wrote: > This announcement is to serve as the beginning of the WGLC for: > > draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 > > http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 > > WGLC runs from Monday Feb 7th to Monday Feb 21st. > > The 01 version of this document received a lot of good feedback on this > list which has been incorporated into this version of the draft. > > joelja From dougb@dougbarton.us Wed Feb 23 23:03:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7610A3A69EB for ; Wed, 23 Feb 2011 23:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZuxPB19WC7s for ; Wed, 23 Feb 2011 23:03:12 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id D5DFF3A69C1 for ; Wed, 23 Feb 2011 23:03:11 -0800 (PST) Received: (qmail 18595 invoked by uid 399); 24 Feb 2011 07:03:56 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 24 Feb 2011 07:03:56 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D6602D6.3040209@dougbarton.us> Date: Wed, 23 Feb 2011 23:03:50 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joel Jaeggli References: <4D4F6887.7050203@bogus.com> <4D65FD06.9030305@bogus.com> In-Reply-To: <4D65FD06.9030305@bogus.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 07:03:15 -0000 On 02/23/2011 22:39, Joel Jaeggli wrote: > Last Call for this document has concluded... > > Jason did an epic job at turning around both the suggested changes and > the minor but relatively numerous language edits suggested. The result > is draft-03 > > here: > > http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 > > and the diff1 output > > here: > > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt > > Barring the signficant gnashing of teeth, we will proceed with a > document shepherd writeup and request IESG publication. Doug Barton's > criticsm will be noted in the document shepherd review which I will > circulate probably Monday. Thanks. > if anyone feels like they might be inclined > to file an appeal at some later date please let me know so I can inlude > that information in the packet for the IESG. "Not I" said the fly. :) It's clear that the mood of the group is to allow the draft to move forward. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From joelja@bogus.com Wed Feb 23 23:32:52 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 741543A68C2 for ; Wed, 23 Feb 2011 23:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOXJj6ZQlYvq for ; Wed, 23 Feb 2011 23:32:51 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 577BB3A681D for ; Wed, 23 Feb 2011 23:32:50 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p1O7XXc1076747 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 24 Feb 2011 07:33:33 GMT (envelope-from joelja@bogus.com) Message-ID: <4D6609CC.2080104@bogus.com> Date: Wed, 23 Feb 2011 23:33:32 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Doug Barton References: <4D4F6887.7050203@bogus.com> <4D65FD06.9030305@bogus.com> <4D6602D6.3040209@dougbarton.us> In-Reply-To: <4D6602D6.3040209@dougbarton.us> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Thu, 24 Feb 2011 07:33:36 +0000 (UTC) Cc: IPv6 Ops WG , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 07:32:52 -0000 On 2/23/11 11:03 PM, Doug Barton wrote: >> Barring the signficant gnashing of teeth, we will proceed with a >> document shepherd writeup and request IESG publication. Doug Barton's >> criticsm will be noted in the document shepherd review which I will >> circulate probably Monday. > > Thanks. > >> if anyone feels like they might be inclined >> to file an appeal at some later date please let me know so I can inlude >> that information in the packet for the IESG. > > "Not I" said the fly. :) It's clear that the mood of the group is to > allow the draft to move forward. Thanks! Joel > > Doug > From fred@cisco.com Thu Feb 24 05:18:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF73F3A6B07 for ; Thu, 24 Feb 2011 05:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5c5Kbc16Od+i for ; Thu, 24 Feb 2011 05:18:03 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D3F603A6806 for ; Thu, 24 Feb 2011 05:18:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=626; q=dns/txt; s=iport; t=1298553533; x=1299763133; h=mime-version:subject:from:date:cc:message-id:to: content-transfer-encoding; bh=gKE/jnGf0P+P5RWumQXu9E31G4JUWBCoDIjc7MaWZc8=; b=hNk3NKNrp/NRHH/UvqOglCar8oy1QexRbg1DwqqZDHpAcPVOtS51Oh9A TEQ8euBYwzT67cgZyGfCAW90OMX/wkvSkN4IPrJ7HVW51ukTGxC+b6ZDA ktc2lFUNqUOpcynN6za4uqr5fcSHIF87BgR1AqHGdsaeSCTrju9s1AoEw c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEGAJPpZU2rRN+J/2dsb2JhbACYFI4Uc6F7m2uFYASFEIcMgz0 X-IronPort-AV: E=Sophos;i="4.62,218,1297036800"; d="scan'208";a="269827478" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 24 Feb 2011 13:18:52 +0000 Received: from Freds-Computer.local ([10.21.87.171]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p1ODIlXE006193; Thu, 24 Feb 2011 13:18:52 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 24 Feb 2011 06:18:52 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 24 Feb 2011 06:18:52 -0700 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker Date: Thu, 24 Feb 2011 06:18:35 -0700 Message-Id: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 13:18:04 -0000 This is to initiate a two week working group last call of = draft-ietf-v6ops-multihoming-without-nat66. Please read it now. If you = find nits (spelling errors, minor suggested wording changes, etc), = comment to the authors; if you find greater issues, such as disagreeing = with a statement or finding additional issues that need to be addressed, = please post your comments to the list. We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make.= From tena@huawei.com Thu Feb 24 11:41:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581E23A6833 for ; Thu, 24 Feb 2011 11:41:04 -0800 (PST) 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.212, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qt5e41mORHTP for ; Thu, 24 Feb 2011 11:40:57 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id E41273A680B for ; Thu, 24 Feb 2011 11:40:56 -0800 (PST) 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 <0LH5009YO01M9E@usaga02-in.huawei.com> for v6ops@ietf.org; Thu, 24 Feb 2011 11:41:46 -0800 (PST) Received: from TingZousc1 ([10.193.34.106]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LH500JDA01KKX@usaga02-in.huawei.com> for v6ops@ietf.org; Thu, 24 Feb 2011 11:41:46 -0800 (PST) Date: Thu, 24 Feb 2011 11:41:44 -0800 From: Tina Tsou In-reply-to: To: "'Livingood, Jason'" Message-id: <00e901cbd45a$de6a88a0$9b3f99e0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gNAaUga+v3LnZAWA6pT0XQ)" Content-language: en-us Thread-index: AQHL0hJMiSnmnTOq9kOktdj8dZOxy5QMg5dQgAGk4gCAAuh+sA== References: <026f01cbd214$a1b71420$e5253c60$@com> Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 19:41:04 -0000 This is a multi-part message in MIME format. --Boundary_(ID_gNAaUga+v3LnZAWA6pT0XQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Jason, I think the wording below is OK. I would see if anyone complains about the wording. It could be a bit more specific. For example, you could add a few words right at the end so instead of ... may present incremental operational and/or technical challenges. it said ... may present incremental operational and/or technical challenges such as a requirement for on-line signing. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Sent: Tuesday, February 22, 2011 8:24 PM To: Tina Tsou Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 Hi Tina - Thank you for your review and specific feedback below. These changes will be in the -03 update soon. See my specific responses inline below. Thanks! Jason On 2/21/11 5:13 PM, "Tina Tsou" wrote: Hi, I generally support this document as attempt on real operational issues involved in the deployment of IPv6. [JL] Thanks! :-) Comments on section 10.1 "DNSSEC Considerations" are below. It says that different answers are sent to different querying hosts. If those are all known in advance, and the server has the DNS zone signing key, it can separately sign the various alternative answer data sets however you want. If they are not known in advance, then you have to have the keys on-line so you can sign answer data in real time. [JL] Good point. I have attempted to make this more clear. Here is how that section now appears. If you think this needs further modification, just say so. DNS security extensions defined in [RFC4033], [RFC4034], and [RFC4035] use cryptographic digital signatures to provide origin authentication and integrity assurance for DNS data. This is done by creating signatures for DNS data on a Security-Aware Authoritative Name Server that can be used by Security-Aware Resolvers to verify the answers. Since DNS whitelisting is implemented on an authoritative server, which provides different answers depending upon which resolver server has sent a query, the DNSSEC chain of trust is not altered. Even though the authoritative server will not always return a AAAA resource record when one exists, respective A resource records and AAAA resource records can and should both be signed. Therefore there are no DNSSEC implications per se. However, any implementer of DNS whitelisting should be careful if they implement both DNSSEC signing of their domain and also DNS whitelisting of that same domain. Specifically, those domains should ensure that resource records are being appropriately and reliably signed, which may present incremental operational and/or technical challenges. Thank you again, Jason We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Livingood, Jason Sent: Monday, February 21, 2011 1:57 PM To: Joel Jaeggli; Doug Barton Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 I proposed a series of edits (sent to jason first due to their length) that neutralize the tone a bit but without I think altering the content. I think that the characterization of the problems with a whitelisting approach is useful and important. It's going to (has) happened anyway and it's not a "we told you so" it's "these are the issues you have to contend with." [JL] I am mid-way through those edits (will take another day or so to factor them all in). These suggestions will be adopted in a -03 version along with the other specific feedback received in the past few days of WGLC. Regards Jason --Boundary_(ID_gNAaUga+v3LnZAWA6pT0XQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Jason,

I think the wording below is OK. I would see if anyone complains about the wording. It could be a bit more specific. For example, you could add a few words right at the end so instead of

 

                ... may present incremental operational and/or technical challenges.

 

it said

 

                ... may present incremental operational and/or technical challenges such as a requirement for on-line signing.

 

 < /span>We keep our promises with one another – no matter what!

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

 

From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
Sent: Tuesday, February 22, 2011 8:24 PM
To: Tina Tsou
Cc: 'IPv6 Ops WG'
Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02

 

< al>Hi Tina – Thank you for your review and specific feedback below. These changes will be in the –03 update soon. See my specific responses inline below.

 

Thanks!

Jason

 

On 2/21/11 5:13 PM, "Tina Tsou" <tena@huawei.com> wrote:

 

Hi,

I generally support this document as attempt on real operational issues involved in the deployment of IPv6.

< p class= nt-family:"Calibri","sans-serif";mso-fareast-font-family:"Times New Roman";color:black'> 

[JL] Thanks! :-)

 

Comments on section 10.1 “DNSSEC Considerations” are below.

It says e sent to different querying hosts. If those are all known in advance, and the server has the DNS zone signing key, it can separately sign the various alternative answer data sets however you want. If they are not known in advance, then you have to have the keys on-line so you can sign answer data in real time…

 

[JL] Good point. I have attempted to make this more clear. Here is how that section now appears. If you think this needs further modification, just say so.

DNS security extensions defined in [RFC4033], [RFC4034], and [RFC4035] use cryptographic digital signatures to provide origin authentication and integrity assurance for DNS data. This is done by creating signatures for DNS data on a Security-Aware Authoritative Name Server that can be used by Secu rity-Awa e answers. Since DNS whitelisting is implemented on an authoritative server, which provides different answers depending upon which resolver server has sent a query, the DNSSEC chain of trust is not altered. Even though the authoritative server will not always return a AAAA resource record when one exists, respective A resource records and AAAA resource records can and should both be signed.  Therefore there are no DNSSEC implications per se. However, any implementer of DNS whitelisting should be careful if they implement both DNSSEC signing of their domain and also DNS whitelisting of that same domain. Specifically, those domains should ensure that resource records are being appropriately and reliably signed, which may present incremental operational and/or technical challenges.

 

 

Thank you again, 

Jason

 

 

 

We keep our promises with one another – no matter what!

 

Best Regards,

Tina TSOU <

http://tinatsou.weebly.com/contact.html

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Livingood, Jason
Sent: Monday, February 21, 2011 1:57 PM
To: Joel Jaeggli; Doug Barton
Cc: t: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02

 


I proposed a series of edits (sent to jason first due to their length)

that neutralize the tone a bit but without I think altering the content.

I think that the characterization of the problems with a whitelistingapproach is useful and important. It's going to (has) happened anyway

and it's not a "we told you so" it's "these are the issues you have to

contend with."

 

[JL] I am mid-way through those edits (will take another day or so to factor them all in). These suggestions will be ad opted in g with the other specific feedback received in the past few days of WGLC.

 

Regards

Jason

--Boundary_(ID_gNAaUga+v3LnZAWA6pT0XQ)-- From joelja@bogus.com Thu Feb 24 14:17:46 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22FA63A683F for ; Thu, 24 Feb 2011 14:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVw-8NtCCFxt for ; Thu, 24 Feb 2011 14:17:45 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 4EB063A6826 for ; Thu, 24 Feb 2011 14:17:44 -0800 (PST) Received: from 23173jjaeggli.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p1OMIP6f023565 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 24 Feb 2011 22:18:27 GMT (envelope-from joelja@bogus.com) Message-ID: <4D66D92B.5010701@bogus.com> Date: Thu, 24 Feb 2011 14:18:19 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tina Tsou References: <026f01cbd214$a1b71420$e5253c60$@com> <00e901cbd45a$de6a88a0$9b3f99e0$@com> In-Reply-To: <00e901cbd45a$de6a88a0$9b3f99e0$@com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Thu, 24 Feb 2011 22:18:28 +0000 (UTC) Cc: 'IPv6 Ops WG' , "'Livingood, Jason'" Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 22:17:46 -0000 I don't think we need to be that specific about how people sort out the issue of signing their zones. if 4470 is required for a particular deployment it's probably because you have some condition or desire other than two differing views of the same zone. On 2/24/11 11:41 AM, Tina Tsou wrote: > Hi Jason, > > I think the wording below is OK. I would see if anyone complains about > the wording. It could be a bit more specific. For example, you could add > a few words right at the end so instead of > > > > ... may present incremental operational and/or technical > challenges. > > > > itsaid > > > > ... may present incremental operational and/or technical > challenges such as a requirement for on-line signing. > > > > < /span>We keep our promises with one another – no matter what! > > > > Best Regards, > > Tina TSOU > > http://tinatsou.weebly.com/contact.html > > > > *From:*Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > *Sent:* Tuesday, February 22, 2011 8:24 PM > *To:* Tina Tsou > *Cc:* 'IPv6 Ops WG' > *Subject:* Re: [v6ops] WGLC > draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 > > > > < al>Hi Tina – Thank you for your review and specific feedback below. > These changes will be in the –03 update soon. See my specific responses > inline below. > > > > Thanks! > > Jason > > > > On 2/21/11 5:13 PM, "Tina Tsou" > wrote: > > > > Hi, > > I generally support this document as attempt on real operational > issues involved in the deployment of IPv6. > > < p class= > nt-family:"Calibri","sans-serif";mso-fareast-font-family:"Times New > Roman";color:black'> > > [JL] Thanks! :-) > > > > Comments on section 10.1 “DNSSEC Considerations” are below. > > It says e sent to different querying hosts. If those are all known > in advance, and the server has the DNS zone signing key, it can > separately sign the various alternative answer data sets however you > want. If they are not known in advance, then you have to have the > keys on-line so you can sign answer data in real time… > > > > [JL] Good point. I have attempted to make this more clear. Here is how > that section now appears. If you think this needs further modification, > just say so. > > /DNS security extensions defined in /*/[RFC4033]/* > <#RFC4033>/, /*/[RFC4034]/* <#RFC4034>/, and /*/[RFC4035]/* > <#RFC4035>/ use cryptographic digital signatures to provide origin > authentication and integrity assurance for DNS data. This is done by > creating signatures for DNS data on a Security-Aware Authoritative Name > Server that can be used by Secu rity-Awa e answers. //Since DNS > whitelisting is implemented on an authoritative server, which provides > different answers depending upon which resolver server has sent a query, > the DNSSEC chain of trust is not altered. Even though the authoritative > server will not always return a AAAA resource record when one exists, > respective A resource records and AAAA resource records can and should > both be signed. Therefore there are no DNSSEC implications per se. > However, any implementer of DNS whitelisting should be careful if they > implement both DNSSEC signing of their domain and also DNS whitelisting > of that same domain. Specifically, those domains should ensure that > resource records are being appropriately and reliably signed, which may > present incremental operational and/or technical challenges./ > > > > > > Thank you again, > > Jason > > > > > > > > We keep our promises with one another – no matter what! > > > > Best Regards, > > Tina TSOU < > > http://tinatsou.weebly.com/contact.html > > > > *From:*v6ops-bounces@ietf.org > [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Livingood, Jason > *Sent:* Monday, February 21, 2011 1:57 PM > *To:* Joel Jaeggli; Doug Barton > *Cc:* t: Re: [v6ops] WGLC > draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 > > > > > I proposed a series of edits (sent to jason first due to their > length) > > that neutralize the tone a bit but without I think altering the > content. > > I think that the characterization of the problems with a > whitelistingapproach is useful and important. It's going to > (has) happened anyway > > and it's not a "we told you so" it's "these are the issues you > have to > > contend with." > > > > [JL] I am mid-way through those edits (will take another day or so > to factor them all in). These suggestions will be ad opted in g with > the other specific feedback received in the past few days of WGLC. > > > > Regards > > Jason > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jav@sics.se Fri Feb 25 06:16:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7EB3A695C for ; Fri, 25 Feb 2011 06:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBz+-f+0PqAQ for ; Fri, 25 Feb 2011 06:16:05 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id D0E893A69D3 for ; Fri, 25 Feb 2011 06:16:04 -0800 (PST) Received: from [193.10.66.199] (dab.sics.se [193.10.66.199]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id D95944035A; Fri, 25 Feb 2011 15:16:55 +0100 (CET) From: Javier Ubillos To: v6ops@ietf.org Content-Type: text/plain; charset="UTF-8" Date: Fri, 25 Feb 2011 15:16:32 +0100 Message-ID: <1298643392.2045.137.camel@dab> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: 'Rashmi' Subject: [v6ops] Happy-eyeballs - P-value & behavior X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 14:16:05 -0000 Hi. As I mentioned previously, we're implementing happy-eyeballs in name-based sockets (all in kernel-space). Here are some thoughts about things we've run into: * Increasing/decreasing the P-value So, the current action table is | Winner | | P | IPv4 | IPv6 | Action | Suggestion +------+------+------+--------+----------- | P<=0 | X | | P -= 1 | +------+------+------+--------+----------- | P>=0 | X | | P /= 2 | P /= -2 +------+------+------+--------+----------- | P<=0 | | X | P /= 2 | P /= -2 +------+------+------+--------+----------- | P>=0 | | X | P += 1 | +------+------+------+--------+----------- | | Both fail | ? | P = 0 +------+------+------+--------+----------- And a case which wouldn't fit in the table, what to do if we cannot determine a winner i.e. both sockets get connected very quickly. I'd like to give IPv6 the edge in that scenario. Also, if both connections fail, I suggest we reset P to 0. Multiplying with -1, consider the scenario: P is high, favouring IPv6 and delaying IPv4 connections. If IPv4 still wins, it means that suddenly is significantly better than IPv6 (it won dispite IPv6's headstart). Shouldn't we multiply P by -1? Does it matter if we start "flapping" between IPv4/6? If it does matter, e.g. we want SSL, wouldn't a slow-flapping ("normal"-P management) be just as bad? If we, instead of dividing by two, divide by -2. We both switch protocol, yet move towards zero, expressing that we are not as confident about the preference. * Why should we keep a P-value at all? After a mail-exchange with Dan Wing, my conclusion is basically, to avoid unnecessary SYN-spamming. Which makes sense to me, SYNs don't have a back-off mechanism as an "ordinary" TCP flow has. However, using a P-value, where P is a delay to be introduced before trying the "other" AF seems sub-optimal to me. Perhaps some other congestion-control for SYNs is more appropriate? A trivial algorithm _could_ be: | Always send a SYN for both IPv4 & IPv6 (be aggressive) | If some SYN does _not_ receive a SYN-ACK begin SYN-congestion-control --> Select the best AF (v4 or v6) according to some criteria | During time T, only use the best AF |* When time T expires, test sending a SYN on the other AF, and see if it gets through (multiple tests?) | If the congestion is gone go to start (i.e resume an aggressive approach) | Else - reset T and resume the timid approach. The reason I'm suggesting a "default" aggressive approach, that I don't think that SYN packets make out a noticeable large fraction of the total amount of traffic. I've started some captures to compare our offices ratio of tcp/tcp-syn packets (overall and for www traffic). * P-scope Currently we're choosing the easy-way out, and keeping a system-wide P. However, I'm assuming that a per-destination P is more relevant. Perhaps even destination+service. I think destination+service is overkill. We _want_ to re-use P and not have to re-init/test too many times. We'll continue with a system wide P for now, but we'll likely go the per-destination P, hopefully with some nice aggregation feature too. My 3 * 2cents. // Javier Ubillos From simon.perreault@viagenie.ca Fri Feb 25 06:39:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EF143A69DB for ; Fri, 25 Feb 2011 06:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0pXh-5UURJx for ; Fri, 25 Feb 2011 06:39:22 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id DA9ED3A69B2 for ; Fri, 25 Feb 2011 06:39:21 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6258620D0D; Fri, 25 Feb 2011 09:40:13 -0500 (EST) Message-ID: <4D67BF4C.6020301@viagenie.ca> Date: Fri, 25 Feb 2011 09:40:12 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Javier Ubillos References: <1298643392.2045.137.camel@dab> In-Reply-To: <1298643392.2045.137.camel@dab> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, 'Rashmi' Subject: Re: [v6ops] Happy-eyeballs - P-value & behavior X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 14:39:26 -0000 On 2011-02-25 09:16, Javier Ubillos wrote: > Hi. > > As I mentioned previously, we're implementing happy-eyeballs in > name-based sockets (all in kernel-space). > > Here are some thoughts about things we've run into: > > * Increasing/decreasing the P-value > > So, the current action table is > | Winner | > | P | IPv4 | IPv6 | Action | Suggestion > +------+------+------+--------+----------- > | P<=0 | X | | P -= 1 | > +------+------+------+--------+----------- > | P>=0 | X | | P /= 2 | P /= -2 > +------+------+------+--------+----------- > | P<=0 | | X | P /= 2 | P /= -2 > +------+------+------+--------+----------- > | P>=0 | | X | P += 1 | > +------+------+------+--------+----------- > | | Both fail | ? | P = 0 > +------+------+------+--------+----------- > And a case which wouldn't fit in the table, what to do if we cannot > determine a winner i.e. both sockets get connected very quickly. I'd > like to give IPv6 the edge in that scenario. Agreed. > Also, if both connections fail, I suggest we reset P to 0. What would justify discarding all accumulated evidence in one shot? > Multiplying with -1, consider the scenario: > P is high, favouring IPv6 and delaying IPv4 connections. > If IPv4 still wins, it means that suddenly is significantly better than > IPv6 (it won dispite IPv6's headstart). > Shouldn't we multiply P by -1? > Does it matter if we start "flapping" between IPv4/6? > If it does matter, e.g. we want SSL, wouldn't a slow-flapping > ("normal"-P management) be just as bad? > > If we, instead of dividing by two, divide by -2. We both switch > protocol, yet move towards zero, expressing that we are not as confident > about the preference. I understand what you're trying to accomplish, but I'm wondering why you're giving so much more importance to the latest result than to the accumulated evidence. Why is it important that we switch right away? Over time, if IPvX maintains its advantage over IPvY, the switch will happen anyway. > * Why should we keep a P-value at all? > > After a mail-exchange with Dan Wing, my conclusion is basically, to > avoid unnecessary SYN-spamming. Which makes sense to me, SYNs don't have > a back-off mechanism as an "ordinary" TCP flow has. However, using a > P-value, where P is a delay to be introduced before trying the "other" > AF seems sub-optimal to me. > Perhaps some other congestion-control for SYNs is more appropriate? > A trivial algorithm _could_ be: > > | Always send a SYN for both IPv4 & IPv6 (be aggressive) > | If some SYN does _not_ receive a SYN-ACK begin > SYN-congestion-control > --> Select the best AF (v4 or v6) according to some criteria > | During time T, only use the best AF > |* When time T expires, test sending a SYN on the other AF, and see > if it gets through (multiple tests?) > | If the congestion is gone go to start (i.e resume an aggressive > approach) > | Else - reset T and resume the timid approach. > > The reason I'm suggesting a "default" aggressive approach, that I don't > think that SYN packets make out a noticeable large fraction of the total > amount of traffic. I've started some captures to compare our offices > ratio of tcp/tcp-syn packets (overall and for www traffic). I agree: SYN spamming does not sound like a big issue to me (need data to back that up). But your algorithm still tries to avoid SYN spamming. I'd go further: - Always send SYN for both IPv4 & IPv6. - If the IPv6 connects first, use it and cancel IPv4. - If the IPv4 connects first, wait 100ms to give IPv6 a chance. - If IPv6 connects within 100ms, use it and cancel IPv4. - Otherwise, cancel IPv6 and use IPv4. The cool thing about this is that it is super simple and stateless. There is one tweakable parameter (sounds like a sysctl to me!). But it assumes that SYN spamming is not an issue. Any idea on how we can test that assumption? > * P-scope > Currently we're choosing the easy-way out, and keeping a system-wide P. > However, I'm assuming that a per-destination P is more relevant. Perhaps > even destination+service. I think destination+service is overkill. We > _want_ to re-use P and not have to re-init/test too many times. > We'll continue with a system wide P for now, but we'll likely go the > per-destination P, hopefully with some nice aggregation feature too. I have evidence that a global P is broken. I'll post it soon. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From richih.mailinglist@gmail.com Fri Feb 25 07:06:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B0913A69C8 for ; Fri, 25 Feb 2011 07:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EQouKE7eRwU for ; Fri, 25 Feb 2011 07:06:39 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 29FC43A69BA for ; Fri, 25 Feb 2011 07:06:39 -0800 (PST) Received: by yic13 with SMTP id 13so850795yic.31 for ; Fri, 25 Feb 2011 07:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=PO8/n0WvnaQKH8rZDMYpbIN57vKrBP2+oYCE8oyP1bU=; b=eFvQ9mE3LdBeqHfZmcSDkp+xtp0hBMp8ow2nyHuT9eQLjsJq42uASS2zf8uAkxnDSx HSmi8aoTbgBYBPC7gYGAAgMbe1rNvWjbeyg07ueKLFEGQakXvS77cvvtvB50daJNtHJQ leMcnYg2lbQbPr+Vdy03I89Ft7HUa4OCbFmYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=XBC89EnXqRLS0wNyS586wmHrUX6IUjg13Rl7o15p+qcgVN7oKxxlNmzt8PyiDO+ODJ TRsar7zDVSfJEYZK6PCSC9wKenn4uUAOoWUYUXYpazZQU1/DW23I9pNT7ozV1ChV0I7w LXPTclOBuyERl7MdzEyIGCRkVQfL8raBURvig= Received: by 10.236.182.2 with SMTP id n2mr4427900yhm.17.1298646446943; Fri, 25 Feb 2011 07:07:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.110.19 with HTTP; Fri, 25 Feb 2011 07:07:06 -0800 (PST) From: Richard Hartmann Date: Fri, 25 Feb 2011 16:07:06 +0100 Message-ID: To: IPv6 Operations Content-Type: text/plain; charset=UTF-8 Subject: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:06:40 -0000 Hi all, I submitted an errata [1] for RFC 4291 and as far as I understand it, an announcement of this should be sent to the relevant WG so people are aware of this and can comment. This hasn't happened yet and I suspect this might be because the WG that released RFC 4291, ipv6, is a concluded WG. Having had to decide between 6man and v6ops, I decided to go with v6ops and hope it was the right choice. So, long story short: I submitted an errata, I don't want it to lie around without peer review and thus decided to poke this list. As usual, thanks for all input and be it merely "don't bother this list with this", Richard PS: I know that "2001:DB8:93::12:0:0:417A an incorrect unicast address" is not the correct wording. I am still trying to find out how to change my errata [1] http://www.rfc-editor.org/errata_search.php?rfc=4291&eid=2735 From volz@cisco.com Fri Feb 25 07:34:46 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31853A69F7 for ; Fri, 25 Feb 2011 07:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXf9Quq5rvoF for ; Fri, 25 Feb 2011 07:34:45 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B0AC23A69D5 for ; Fri, 25 Feb 2011 07:34:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=1540; q=dns/txt; s=iport; t=1298648138; x=1299857738; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=hkTRUrA2IyqYrDvjpxIj4YdY47ppWRcH9eK6CPrzcIg=; b=TyAIgpspr9msTHzRxT4gT8Wg+++K5cbEK5VSKyvBoBFGrzRzAQFB/vxQ AlE5svEoNPsD3+a5XPSIXXEyymR6mxXoSYiokVsTrZiucl3uiuVD9Y16N 5wp961bygXGrRzwVSq4Hgy4+TwilNtbf5bfbM2AfO4oapD6BZVTazs7Lz Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBAHxaZ02tJV2a/2dsb2JhbACXao5RdIg7mQmbbYVgBIUQilGJNw X-IronPort-AV: E=Sophos;i="4.62,225,1297036800"; d="scan'208";a="664495103" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-6.cisco.com with ESMTP; 25 Feb 2011 15:35:38 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1PFZcDp015117; Fri, 25 Feb 2011 15:35:38 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Feb 2011 09:35:38 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Feb 2011 09:35:36 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Errata 2735 for RFC4291 Thread-Index: AcvU/cPMI2z4E8GRRpCInJUODQaQ4gAArpQg References: From: "Bernie Volz (volz)" To: "Richard Hartmann" , "IPv6 Operations" X-OriginalArrivalTime: 25 Feb 2011 15:35:38.0120 (UTC) FILETIME=[A6DA5080:01CBD501] Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:34:47 -0000 Existing parsing code generally has allowed :: to mean one or more groups of 16-bits. Think of this as :[0]: - it saves one character. And, for that reason it should be valid for both input and output. Thus, I don't support this Errata (whatever that might mean). - Bernie -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Richard Hartmann Sent: Friday, February 25, 2011 10:07 AM To: IPv6 Operations Subject: [v6ops] Errata 2735 for RFC4291 Hi all, I submitted an errata [1] for RFC 4291 and as far as I understand it, an announcement of this should be sent to the relevant WG so people are aware of this and can comment. This hasn't happened yet and I suspect this might be because the WG that released RFC 4291, ipv6, is a concluded WG. Having had to decide between 6man and v6ops, I decided to go with v6ops and hope it was the right choice. So, long story short: I submitted an errata, I don't want it to lie around without peer review and thus decided to poke this list. As usual, thanks for all input and be it merely "don't bother this list with this", Richard PS: I know that "2001:DB8:93::12:0:0:417A an incorrect unicast address" is not the correct wording. I am still trying to find out how to change my errata [1] http://www.rfc-editor.org/errata_search.php?rfc=3D4291&eid=3D2735 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From russell@heilling.net Fri Feb 25 07:44:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 807B13A69FA for ; Fri, 25 Feb 2011 07:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBQMgKgxpBgx for ; Fri, 25 Feb 2011 07:44:16 -0800 (PST) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 696A33A69F7 for ; Fri, 25 Feb 2011 07:44:16 -0800 (PST) Received: by pvd12 with SMTP id 12so346470pvd.31 for ; Fri, 25 Feb 2011 07:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heilling.net; s=google; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aaKnpND/lA1iRhvAVdYMkTMjWt3RfgVIrb5dLN0OaGM=; b=Nz41+Cxl3eSq07hA9wejtu+MfYlW8Vp7ScG1sL+iS7WouBV0+f+WoiiEm3UJJ/cAMr s0bI8m3JDzfuFfmKgFYBF7K4dWnRWR8Ql7/OSftgrTp2HL0w+5QaaunypUliDUZ293yr U8IxQIfEwIJ2Q4/ryRm6CyyAEPDP626U+axL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=heilling.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZUzAUJvoeEedJ7opVVxWCFl6F3AI/AneW3/8J17HzbZRHOC4RryvuZGxKGx2eMR4VS UU4TEKKEsGH1uhCz7CAOro7NEGm5na9l9Za7V1WwCtiB/l7H/8tFFRlqwieFZ/CJzPTV wyMgkKmGtHCLcxnhHH4UE9D/vGHB5lJlpfeoM= MIME-Version: 1.0 Received: by 10.142.242.9 with SMTP id p9mr1762427wfh.291.1298648708535; Fri, 25 Feb 2011 07:45:08 -0800 (PST) Received: by 10.142.47.4 with HTTP; Fri, 25 Feb 2011 07:45:08 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Feb 2011 15:45:08 +0000 Message-ID: From: Russell Heilling To: Richard Hartmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:44:17 -0000 On 25 February 2011 15:07, Richard Hartmann wrote: > Hi all, > > > I submitted an errata [1] for RFC 4291 and as far as I understand it, > an announcement of this should be sent to the relevant WG so people > are aware of this and can comment. > > This hasn't happened yet and I suspect this might be because the WG > that released RFC 4291, ipv6, is a concluded WG. I am not sure that any action is required on this errata. RFC5952, which is a standards track RFC and listed as updating RFC4291, specifically addresses the usage of '::' for zero compression. I also feel that the alignment of the 16-bit fields is clear from the context in 2.2.1, and does not need to be made explicit in this way. --=20 Russell Heilling=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://perl= monkey.blogspot.com "The amazing ability of the bee to adapt herself often helps the =A0beekeeper to overcome the results of his ignorance." - Brother Adam From richih.mailinglist@gmail.com Fri Feb 25 07:47:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F1E3A69E2 for ; Fri, 25 Feb 2011 07:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtIRUKXDQEN8 for ; Fri, 25 Feb 2011 07:47:20 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E196A3A695C for ; Fri, 25 Feb 2011 07:47:19 -0800 (PST) Received: by iwl42 with SMTP id 42so1349192iwl.31 for ; Fri, 25 Feb 2011 07:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CoVz5qXfFi2De0F0t1+X5pIWxYKblveFvzwah2ZLyKs=; b=PGKPSwgIOxFf8635w+mB6vRQOu/xveaNE2i9O5IGu4aY9hJZJjzFU3k/pdRe1ezjz8 JSNhRP7kF98U/NRT/nF/XngftYBM9rIO4yBQRTP+Tx8jn7D/nu6WHhH7LYjFGZf7U5Xn dQpZgIQl62Yo8dM36RvYBRZQyggP0qRy7VoaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Me8DVIfqEwOc/r+Co5AqgRySLZwODBFgWdgHTo9Q7lhHbodXaqe/pWVph+Q12U5RJR lGPKiQhj8dQjMPK7aJy5UagV8qDo4BdxgSAUDTTFgrG8SRu9ZvElQqhlqiS+kQO0LO70 I6SWnOEhbz1oE4F8FVOY8sfr25dTdu/ET0b8Q= Received: by 10.231.35.136 with SMTP id p8mr2927276ibd.139.1298648892128; Fri, 25 Feb 2011 07:48:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.168.136 with HTTP; Fri, 25 Feb 2011 07:47:52 -0800 (PST) In-Reply-To: References: From: Richard Hartmann Date: Fri, 25 Feb 2011 16:47:52 +0100 Message-ID: To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:47:20 -0000 On Fri, Feb 25, 2011 at 16:35, Bernie Volz (volz) wrote: > Existing parsing code generally has allowed :: to mean one or more > groups of 16-bits. Think of this as :[0]: - it saves one character. And, > for that reason it should be valid for both input and output. I think you are misreading my errata. The current RFCs allow me to compress 2001:DB8:9300:0:12:0:0:417A to 2001:DB8:93::12:0:0:417A which, uncompresses to 2001:DB8:0093:0:12:0:0:417A While I doubt any implementation allows this, it's still an error in the RFCs. If any implementation followed the letter of the RFCs in this matter, it could lead to rather grave consequences. Richard From richih.mailinglist@gmail.com Fri Feb 25 07:49:58 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683C33A6A02 for ; Fri, 25 Feb 2011 07:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDJXIG0gcNnY for ; Fri, 25 Feb 2011 07:49:57 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 887F63A6A00 for ; Fri, 25 Feb 2011 07:49:57 -0800 (PST) Received: by iwl42 with SMTP id 42so1351861iwl.31 for ; Fri, 25 Feb 2011 07:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Py+CsAoXeuF0p//qwtYrYl9eYQR14i6grQsO35R9pZ4=; b=jYbWOw9fTdJ1KxzEmLZhI804ydV31rcxJeEd57zPCNULiMxm3oiu3rwNt6lyna13JE fwGgJ0XqBbN8A4xbWHmagtZWiJpUBdSul4P0rweJGnZuhi8X+QJ5bOhi/EPu8e0i627y TGDFJyEyXpgepNk3LZd0K6AAayUK7GDw9j+84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=h2CzCvMI+LhlGTyTvdjDuUB0oXmAciHreC6F6bZM4Foy1QkuykzfPq7Sg5eaZzj5oB 0A+UN2nW+mJVKkIxzaa34WV7hVkxBTiW/jd0DXAXf2ryed9MXpcyGBKc4+XGgFrupucs 9eVT4C+uQJdP9oIDBA/E0GUoZh52EFn3PtAmE= Received: by 10.42.240.197 with SMTP id lb5mr933016icb.25.1298649050134; Fri, 25 Feb 2011 07:50:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.168.136 with HTTP; Fri, 25 Feb 2011 07:50:30 -0800 (PST) In-Reply-To: References: From: Richard Hartmann Date: Fri, 25 Feb 2011 16:50:30 +0100 Message-ID: To: Russell Heilling Content-Type: text/plain; charset=UTF-8 Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:49:58 -0000 On Fri, Feb 25, 2011 at 16:45, Russell Heilling wrote: > I am not sure that any action is required on this errata. Me neither. But from how I understand the process, the appropriate WGs need to be informed of errata, it hadn't happened and thus I did it myself. > RFC5952, > which is a standards track RFC and listed as updating RFC4291, > specifically addresses the usage of '::' for zero compression. So you're saying I should have filed the errata against RFC 5952? > I also feel that the alignment of the 16-bit fields is clear from the > context in 2.2.1, and does not need to be made explicit in this way. While I am not that familiar with the RFC process, I doubt implicit definitions are a good way to write them. Richard From volz@cisco.com Fri Feb 25 07:55:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3185E3A6A00 for ; Fri, 25 Feb 2011 07:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.299 X-Spam-Level: X-Spam-Status: No, score=-11.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGRQUMuSZPRz for ; Fri, 25 Feb 2011 07:55:15 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 112DA3A69ED for ; Fri, 25 Feb 2011 07:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=1634; q=dns/txt; s=iport; t=1298649368; x=1299858968; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=QGmvqIjIyh7f/VEYVCcgrUjcushwnYKcAB8Dt1vLtAI=; b=XbJPAuIUInPcgB7oOEBc5zNfhzKUMmx9USec116bH4XNk9HJSZtQb/PK XTqAWzJx9w0ek6xQl5VoFIH8s7N8utQMJdZtH/DEyGac7xIqPOAFkRQQD BHhfyfz76rQqEEpkGQjsTLzmw72Gcykv+6gcoYvVkb+nLl0Yfz9gY9LAJ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAGdfZ02tJXG+/2dsb2JhbACEJZNFjW9idKE8iwSQaYEng0N2BIUQilGDDQ X-IronPort-AV: E=Sophos;i="4.62,225,1297036800"; d="scan'208";a="220357265" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rtp-iport-2.cisco.com with ESMTP; 25 Feb 2011 15:56:07 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1PFu7EO008058; Fri, 25 Feb 2011 15:56:07 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Feb 2011 09:56:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 25 Feb 2011 09:56:05 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Errata 2735 for RFC4291 Thread-Index: AcvVA2yUcEEV26Q9SCiQwI1UbOLBbAAAMLtw References: From: "Bernie Volz (volz)" To: "Richard Hartmann" X-OriginalArrivalTime: 25 Feb 2011 15:56:07.0183 (UTC) FILETIME=[836E71F0:01CBD504] Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:55:16 -0000 QnV0IHlvdSBjaGFuZ2VkOg0KDQoJVGhlIHVzZSBvZiAiOjoiIGluZGljYXRlcyBvbmUgb3IgbW9y ZSBncm91cHMgb2YgMTYgYml0cyBvZiB6ZXJvcy4NCg0KVG86DQoNCglUaGUgdXNlIG9mICI6OiIg aW5kaWNhdGVzIHR3byBvciBtb3JlIGdyb3VwcyBvZiAxNiBiaXRzIG9mIHplcm9zLg0KDQoNCkkg Y2VydGFpbmx5IG1pc3NlZCB0aGF0IG90aGVyIHBhcnQgYnV0IEkgbmV2ZXIgdGhvdWdodCB0aGF0 IHdhcyB1bmNsZWFyLg0KDQotIEJlcm5pZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogUmljaGFyZCBIYXJ0bWFubiBbbWFpbHRvOnJpY2hpaC5tYWlsaW5nbGlzdEBnbWFpbC5j b21dIA0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyNSwgMjAxMSAxMDo0OCBBTQ0KVG86IEJlcm5p ZSBWb2x6ICh2b2x6KQ0KQ2M6IElQdjYgT3BlcmF0aW9ucw0KU3ViamVjdDogUmU6IFt2Nm9wc10g RXJyYXRhIDI3MzUgZm9yIFJGQzQyOTENCg0KT24gRnJpLCBGZWIgMjUsIDIwMTEgYXQgMTY6MzUs IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb20+IHdyb3RlOg0KDQo+IEV4aXN0aW5n IHBhcnNpbmcgY29kZSBnZW5lcmFsbHkgaGFzIGFsbG93ZWQgOjogdG8gbWVhbiBvbmUgb3IgbW9y ZQ0KPiBncm91cHMgb2YgMTYtYml0cy4gVGhpbmsgb2YgdGhpcyBhcyA6WzBdOiAtIGl0IHNhdmVz IG9uZSBjaGFyYWN0ZXIuIEFuZCwNCj4gZm9yIHRoYXQgcmVhc29uIGl0IHNob3VsZCBiZSB2YWxp ZCBmb3IgYm90aCBpbnB1dCBhbmQgb3V0cHV0Lg0KDQpJIHRoaW5rIHlvdSBhcmUgbWlzcmVhZGlu ZyBteSBlcnJhdGEuDQoNClRoZSBjdXJyZW50IFJGQ3MgYWxsb3cgbWUgdG8gY29tcHJlc3MNCg0K ICAyMDAxOkRCODo5MzAwOjA6MTI6MDowOjQxN0ENCg0KdG8NCg0KICAyMDAxOkRCODo5Mzo6MTI6 MDowOjQxN0ENCg0Kd2hpY2gsIHVuY29tcHJlc3NlcyB0bw0KDQogIDIwMDE6REI4OjAwOTM6MDox MjowOjA6NDE3QQ0KDQpXaGlsZSBJIGRvdWJ0IGFueSBpbXBsZW1lbnRhdGlvbiBhbGxvd3MgdGhp cywgaXQncyBzdGlsbCBhbiBlcnJvciBpbg0KdGhlIFJGQ3MuIElmIGFueSBpbXBsZW1lbnRhdGlv biBmb2xsb3dlZCB0aGUgbGV0dGVyIG9mIHRoZSBSRkNzIGluDQp0aGlzIG1hdHRlciwgaXQgY291 bGQgbGVhZCB0byByYXRoZXIgZ3JhdmUgY29uc2VxdWVuY2VzLg0KDQoNClJpY2hhcmQNCg== From edward.jankiewicz@sri.com Fri Feb 25 08:00:54 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD3A33A695C for ; Fri, 25 Feb 2011 08:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UympHIVDBoYn for ; Fri, 25 Feb 2011 08:00:53 -0800 (PST) Received: from mail1.sri.com (srimail.SRI.COM [128.18.30.17]) by core3.amsl.com (Postfix) with ESMTP id DECBE3A67C2 for ; Fri, 25 Feb 2011 08:00:53 -0800 (PST) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_+H0XG2UeHlsXK7kKBm2xnw)" Received: from [192.168.1.144] ([unknown] [68.81.23.64]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LH6002YAKIXME80@mail.sri.com> for v6ops@ietf.org; Fri, 25 Feb 2011 08:01:46 -0800 (PST) Message-id: <4D67D267.5070500@sri.com> Date: Fri, 25 Feb 2011 11:01:43 -0500 From: Ed Jankiewicz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 To: "nav6tf@ipv6forum.com" , IPv6 TWG , IPv6 Ops WG Subject: [v6ops] IPv6 Jumps the Shark X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 16:00:54 -0000 This is a multi-part message in MIME format. --Boundary_(ID_+H0XG2UeHlsXK7kKBm2xnw) Content-type: multipart/alternative; boundary="Boundary_(ID_yyLCtZM9oGD0fqcCmngdUA)" --Boundary_(ID_yyLCtZM9oGD0fqcCmngdUA) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT When used for entertainment purposes, a technology has truly matured. http://xkcd.com/865/ -- Edward J Jankiewicz, Senior Technical Advisor Engineering and Systems Group -- Information Systems Division SRI International, Inc. edward.jankiewicz@sri.com Google Voice: (908) 718-1335 --Boundary_(ID_yyLCtZM9oGD0fqcCmngdUA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT When used for entertainment purposes, a technology has truly matured.

http://xkcd.com/865/


-- 
Edward J Jankiewicz, Senior Technical Advisor  
Engineering and Systems Group -- Information Systems Division
SRI International, Inc.
edward.jankiewicz@sri.com
Google Voice: (908) 718-1335
--Boundary_(ID_yyLCtZM9oGD0fqcCmngdUA)-- --Boundary_(ID_+H0XG2UeHlsXK7kKBm2xnw) Content-type: text/x-vcard; CHARSET=US-ASCII; name=edward_jankiewicz.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=edward_jankiewicz.vcf begin:vcard fn:Ed Jankiewicz n:Jankiewicz;Ed org:SRI International, Inc.;Engineering and Systems Group, Information Systems Division adr:;;333 Ravenswood Ave;Menlo Park;CA;94025-3453;USA email;internet:ed.jankiewicz@sri.com title:Senior Technical Advisor tel;work:732-389-1003 note:Senior Technical Advisor for Business Development x-mozilla-html:FALSE url:http://www.sri.com/ version:2.1 end:vcard --Boundary_(ID_+H0XG2UeHlsXK7kKBm2xnw)-- From richih.mailinglist@gmail.com Fri Feb 25 08:32:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75D4B3A67A2 for ; Fri, 25 Feb 2011 08:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.832 X-Spam-Level: X-Spam-Status: No, score=-3.832 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGtXCD7K63yD for ; Fri, 25 Feb 2011 08:32:27 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A6AAF3A63EB for ; Fri, 25 Feb 2011 08:32:27 -0800 (PST) Received: by iwl42 with SMTP id 42so1392290iwl.31 for ; Fri, 25 Feb 2011 08:33:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UjeSon4oZQDOfN0/VYYokYMpNzDo713Xn0gVmHaVkwA=; b=N8RwsIkoZd3MVGjoEGY1BEb6RHu3sytAB6La9vIlhZpQJf5iRcQtkrjOtZudSge6Gu eVULFltB+yAWTbl53EtPB8bQKwT+YhdvLOQapg4DhPAHQB4flPFAlqmDYrLLEWkbJ1fx 7GOmKVr/b6oNWktqt9BiOJ4WXktLQmMWQo4tE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=wL8vVSe0XV/PzDRAoaYkgtUnCAhceM6hmnJpBJ86zUq4A02QwqffzpqOWOHqLPPFS0 To1EfvjGcZ+sU3aa4mL57sk2dqklKdUlTu0PKAepC4SA0/HbPUKJ99eH5AUVNDgGl9uj 8vFdC3567njZoqqcirChuJAtUZeh1vkBJFv3E= Received: by 10.231.200.134 with SMTP id ew6mr2948319ibb.164.1298651600157; Fri, 25 Feb 2011 08:33:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.168.136 with HTTP; Fri, 25 Feb 2011 08:33:00 -0800 (PST) In-Reply-To: References: From: Richard Hartmann Date: Fri, 25 Feb 2011 17:33:00 +0100 Message-ID: To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 16:32:28 -0000 On Fri, Feb 25, 2011 at 16:56, Bernie Volz (volz) wrote: > But you changed: [...] Correct. As noted in the notes, errata 2466 changed this and I didn't want to have our erratas overlapping. Richard From russell@heilling.net Fri Feb 25 09:21:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22C0F3A67AE for ; Fri, 25 Feb 2011 09:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.813, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7noIqzl6E552 for ; Fri, 25 Feb 2011 09:21:18 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id D83B53A65A5 for ; Fri, 25 Feb 2011 09:21:18 -0800 (PST) Received: by pzk30 with SMTP id 30so362605pzk.31 for ; Fri, 25 Feb 2011 09:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heilling.net; s=google; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ExnSPAW3n4z6ifzq/po6SGbCWz8orBFIKBs13bcVnec=; b=MA2BXytPA3ZbrEcz31Z3trFrHsPoa2cR7DuL6Gvsbems2qz6j43IASYDg2CVbPYcEq AulD0QfQ5e9zLkdPsHsitVB5mIpC1j6odOOcLOoSH4M6xe1U4vXsZC/7g4UJp3EFPD4J 099b89WRyl3b3NkvurMT5dVLqa4eWeH+cysaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=heilling.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IST+YuceA0ZhsfsE98b0ZR5vOAe+wUy9mMstOU/Al5zK96TLUu4SEKdItCeeIzuJZH YLuVSR9XctQQyy2byB/C298lHqqmZDZ+w7nzk9DTb0reCIOWgTQEmUsDkvhlPDoyOG6I Pgz780Ob3U/NkomYdjPZ14kP4yZPc1ukEE4AU= MIME-Version: 1.0 Received: by 10.142.48.9 with SMTP id v9mr1818221wfv.405.1298654531459; Fri, 25 Feb 2011 09:22:11 -0800 (PST) Received: by 10.142.47.4 with HTTP; Fri, 25 Feb 2011 09:22:11 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Feb 2011 17:22:11 +0000 Message-ID: From: Russell Heilling To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:21:20 -0000 On 25 February 2011 15:56, Bernie Volz (volz) wrote: > But you changed: > > =A0 =A0 =A0 =A0The use of "::" indicates one or more groups of 16 bits of= zeros. > > To: > > =A0 =A0 =A0 =A0The use of "::" indicates two or more groups of 16 bits of= zeros. > > > I certainly missed that other part but I never thought that was unclear. This part is also in RFC5952: The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field > -----Original Message----- > From: Richard Hartmann [mailto:richih.mailinglist@gmail.com] > Sent: Friday, February 25, 2011 10:48 AM > To: Bernie Volz (volz) > Cc: IPv6 Operations > Subject: Re: [v6ops] Errata 2735 for RFC4291 > > The current RFCs allow me to compress > > =A02001:DB8:9300:0:12:0:0:417A > > to > > =A02001:DB8:93::12:0:0:417A That would actually be compressing 24-bits, which is not allowed by the RFC, which refers to "one or more 16-bit fields" I guess in theory the current wording would allow 2001:db8:9300:0093:12:0:0:417a to be compressed as 2001:db8:93::93:12:0:0:417a, which is obviously incorrect. As you point out, I think the problem is with the implicit definition of a 16-bit field in 2.2.1 i.e. change: The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to four hexadecimal digits of the eight 16-bit pieces of the address. to The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to four hexadecimal digits of the eight 16-bit pieces of the address, subsequently referred to as "fields" As you also pointed out, the work on draft-denog-v6ops-addresspartnaming is currently leaning towards "hextet" here instead of "field", but field is what is used currently in both 4291 and 5952. > which, uncompresses to > > =A02001:DB8:0093:0:12:0:0:417A > > While I doubt any implementation allows this, it's still an error in > the RFCs. If any implementation followed the letter of the RFCs in > this matter, it could lead to rather grave consequences. > > > Richard > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Russell Heilling=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://perl= monkey.blogspot.com "The amazing ability of the bee to adapt herself often helps the =A0beekeeper to overcome the results of his ignorance." - Brother Adam From ayourtch@cisco.com Fri Feb 25 09:34:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 380EE3A69EF for ; Fri, 25 Feb 2011 09:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALDfiMps29U3 for ; Fri, 25 Feb 2011 09:34:21 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id D0DE33A69F5 for ; Fri, 25 Feb 2011 09:34:19 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1PHZB5I004534; Fri, 25 Feb 2011 18:35:11 +0100 (CET) Received: from sweet-brew-4.cisco.com (sweet-brew-4.cisco.com [144.254.10.205]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1PHZ9w1016330; Fri, 25 Feb 2011 18:35:09 +0100 (CET) Date: Fri, 25 Feb 2011 18:35:09 +0100 (CET) From: Andrew Yourtchenko To: Javier Ubillos In-Reply-To: <1298643392.2045.137.camel@dab> Message-ID: References: <1298643392.2045.137.camel@dab> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, 'Rashmi' Subject: Re: [v6ops] Happy-eyeballs - P-value & behavior X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:34:22 -0000 Hi Javier, On Fri, 25 Feb 2011, Javier Ubillos wrote: > Hi. > > As I mentioned previously, we're implementing happy-eyeballs in > name-based sockets (all in kernel-space). > > Here are some thoughts about things we've run into: > > * Increasing/decreasing the P-value > > So, the current action table is > | Winner | > | P | IPv4 | IPv6 | Action | Suggestion > +------+------+------+--------+----------- > | P<=0 | X | | P -= 1 | > +------+------+------+--------+----------- > | P>=0 | X | | P /= 2 | P /= -2 > +------+------+------+--------+----------- > | P<=0 | | X | P /= 2 | P /= -2 > +------+------+------+--------+----------- > | P>=0 | | X | P += 1 | > +------+------+------+--------+----------- > | | Both fail | ? | P = 0 > +------+------+------+--------+----------- > And a case which wouldn't fit in the table, what to do if we cannot > determine a winner i.e. both sockets get connected very quickly. I'd > like to give IPv6 the edge in that scenario. I agree. (we want the IPv6 to be the preferred protocol, all other things equal). > Also, if both connections fail, I suggest we reset P to 0. Seems like it won't be a big deal - but do you have more details on the motivation behind ? If both connections failed, that would say either about the very sketchy connectivity of the target, or possibly that the source has lost their connectivity on that interface. If the latter, then I think resetting would make sense under the assumption that we have a different attachment later. If that happens more often than either the target total unreachability or the 'spurious connectivity losses' (like, bad connectivity on wireless). > > Multiplying with -1, consider the scenario: > P is high, favouring IPv6 and delaying IPv4 connections. > If IPv4 still wins, it means that suddenly is significantly better than > IPv6 (it won dispite IPv6's headstart). > Shouldn't we multiply P by -1? > Does it matter if we start "flapping" between IPv4/6? > If it does matter, e.g. we want SSL, wouldn't a slow-flapping > ("normal"-P management) be just as bad? I think this would optimize the case where we switched a link - but deoptimize the case where we had a one-time blip in the connectivity ? > > If we, instead of dividing by two, divide by -2. We both switch > protocol, yet move towards zero, expressing that we are not as confident > about the preference. I think in a much smaller part it might have the same property as my previous paragraph - but I think this might be worth experimenting with. > > > * Why should we keep a P-value at all? > > After a mail-exchange with Dan Wing, my conclusion is basically, to > avoid unnecessary SYN-spamming. Which makes sense to me, SYNs don't have > a back-off mechanism as an "ordinary" TCP flow has. However, using a I think not only SYN-spamming - but also accept()-spamming on the server side I think. Arguably from the capacity planning a host should be able to support 2x accept()-load - but if this is normal scenario, that seems like a bit of a waste. (This is a theoretical view 'in case everyone implemented this', obviously do not apply in the beginning) > P-value, where P is a delay to be introduced before trying the "other" > AF seems sub-optimal to me. > Perhaps some other congestion-control for SYNs is more appropriate? > A trivial algorithm _could_ be: > > | Always send a SYN for both IPv4 & IPv6 (be aggressive) > | If some SYN does _not_ receive a SYN-ACK begin > SYN-congestion-control > --> Select the best AF (v4 or v6) according to some criteria > | During time T, only use the best AF > |* When time T expires, test sending a SYN on the other AF, and see > if it gets through (multiple tests?) > | If the congestion is gone go to start (i.e resume an aggressive > approach) > | Else - reset T and resume the timid approach. > > The reason I'm suggesting a "default" aggressive approach, that I don't > think that SYN packets make out a noticeable large fraction of the total > amount of traffic. I've started some captures to compare our offices > ratio of tcp/tcp-syn packets (overall and for www traffic). While we're thinking radically different ideas: how about a "zebra retransmit". Start with your "favourite" AF, and if you need to retransmit - then send the SYN for a different AF. This way the amount of SYNs will always be exactly the same. If more than 50% of the time over a certain period you fallback - change your favourite protocol. This idea would get nuked by the purists, I suspect :-) > > > * P-scope > Currently we're choosing the easy-way out, and keeping a system-wide P. > However, I'm assuming that a per-destination P is more relevant. Perhaps > even destination+service. I think destination+service is overkill. We > _want_ to re-use P and not have to re-init/test too many times. > We'll continue with a system wide P for now, but we'll likely go the > per-destination P, hopefully with some nice aggregation feature too. How is the PMTUD info stored ? I think that the connectivity characteristics may be related to the PMTUD. P might then sit nicely in one of the address families alongside with MSS ? cheers, andrew > > My 3 * 2cents. > // Javier Ubillos > From richih.mailinglist@gmail.com Fri Feb 25 11:31:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112F83A69F2 for ; Fri, 25 Feb 2011 11:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.774 X-Spam-Level: X-Spam-Status: No, score=-3.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdpdzuMuZmrG for ; Fri, 25 Feb 2011 11:31:26 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 1EBA83A6831 for ; Fri, 25 Feb 2011 11:31:26 -0800 (PST) Received: by yxk30 with SMTP id 30so952889yxk.31 for ; Fri, 25 Feb 2011 11:32:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=icVvgqc9Aa42nFhSRvKE24AvkxtKF7AR2fwuDOvDb2g=; b=Wq6DBoityt274icv/HufsdZ5YkrhWBXzOOoE15o1Pw7L9+J0RAL5r9HXR2XYOzKdmz 4wML7vY0useMS4PelKUPXWcWFUt6+9W07GPgVxkU3JHlWYx/9AIFik/QB2dMYNXcTRGb SmQGCAYaRG6KcmCKsE9YkKDa6Dnibp50YqKlI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=TC1v2FYbul+cnWnYKQFTMEJ58ebYsrUHqn7qMeQE7trWvDgpryZuHfQ84JqRYgA4te jM4tww8Fnu+KpG9Ts+UpGOjU/WyqqIKP/lcL859tG13e+4GR4fYG5BwnoyTeZxWkkRI3 udb77e53RNLH2jNTi+QmxwYK2/6EwF0n+ab9Q= Received: by 10.236.109.11 with SMTP id r11mr175412yhg.95.1298662333113; Fri, 25 Feb 2011 11:32:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.110.19 with HTTP; Fri, 25 Feb 2011 11:31:50 -0800 (PST) In-Reply-To: References: From: Richard Hartmann Date: Fri, 25 Feb 2011 20:31:50 +0100 Message-ID: To: Russell Heilling Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:31:27 -0000 On Fri, Feb 25, 2011 at 18:22, Russell Heilling wrot= e: >> =C2=A02001:DB8:9300:0:12:0:0:417A >> =C2=A02001:DB8:93::12:0:0:417A > > That would actually be compressing 24-bits, which is not allowed by > the RFC, which refers to "one or more 16-bit fields" No, as this are 32 bit: 2001:0DB8:9300:0000:0012:0000:0000:417A ^^ ^^^^ ^^ I chose an example as broken as this on purpose. But apparently I didn't do a very good job in writing the errata, nor in the notes that accompany it. If anyone has any alternate suggestions...? > As you point out, I think the problem is with the implicit definition > of a 16-bit field in 2.2.1 > > i.e. change: > > =C2=A0 =C2=A0 =C2=A0The preferred form is x:x:x:x:x:x:x:x, where the 'x's= are one to > =C2=A0 =C2=A0 =C2=A0four hexadecimal digits of the eight 16-bit pieces of= the address. > > to > > =C2=A0 =C2=A0 =C2=A0The preferred form is x:x:x:x:x:x:x:x, where the 'x's= are one to > =C2=A0 =C2=A0 =C2=A0four hexadecimal digits of the eight 16-bit pieces of= the address, > =C2=A0 =C2=A0 =C2=A0subsequently referred to as "fields" In that case, everything else would need to be changed to refer to field as well. This works from the logical POV, but it's probably easier for humans to have the rule stated explicitly rather than changing from a weak to a binding implication. Thanks for your feedback, Richard From brian.e.carpenter@gmail.com Fri Feb 25 11:33:32 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711EB3A6A16 for ; Fri, 25 Feb 2011 11:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWtkKbj-Dbm5 for ; Fri, 25 Feb 2011 11:33:31 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id EF2F13A6831 for ; Fri, 25 Feb 2011 11:33:30 -0800 (PST) Received: by fxm15 with SMTP id 15so2057835fxm.31 for ; Fri, 25 Feb 2011 11:34:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=M0MDvkn1qVLin1JzvqfzmEIy67B0WJTSAH6AtQ+9zNw=; b=nSpVrsYSIB4fYetENER3+3tynNjWl1sF81Zj5ZfRU/u94Vw0KPB6EI69vOWoKN8XES sBvA9bmg/bZbvF/LloDUAmdCtJ6VRpgypVB51HglAA6rbB8AfPxBj/FKjHpxTWnyaiq1 MiNwmiXQxCoTyoCuZshweSe+HtcnpJwdRCIvs= 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=MnEGO+7eNKWvqoO4sZM3igCdUMXcl0+D93uqKejGP/+kLJ7sPBAd5TbT0+Sft8OJdq ZVVedYnt4ON8q2mgn9Z5OLdVvFTU80nuhrerPqWP+V6BsOuS+PLuDVOh8VKcUr6qy2ke jAKrJ+0n1IKMC1qICFmLRSk4tiHY4wjtLPbs0= Received: by 10.223.95.203 with SMTP id e11mr3144290fan.60.1298662462627; Fri, 25 Feb 2011 11:34:22 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id n26sm497852fam.13.2011.02.25.11.34.18 (version=SSLv3 cipher=OTHER); Fri, 25 Feb 2011 11:34:21 -0800 (PST) Message-ID: <4D680434.9030407@gmail.com> Date: Sat, 26 Feb 2011 08:34:12 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ed Jankiewicz References: <4D67D267.5070500@sri.com> In-Reply-To: <4D67D267.5070500@sri.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "nav6tf@ipv6forum.com" , IPv6 TWG , IPv6 Ops WG Subject: Re: [v6ops] IPv6 Jumps the Shark X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:33:32 -0000 O...K Can someone explain the reference to 1998? That was way after the first implementations came out, so what's the point (apart from being the date on RFC 2460)? The size of the address space was fixed in 1994. Regards Brian On 2011-02-26 05:01, Ed Jankiewicz wrote: > When used for entertainment purposes, a technology has truly matured. > > > http://xkcd.com/865/ > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Fri Feb 25 11:45:37 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F0BD3A6831 for ; Fri, 25 Feb 2011 11:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.157 X-Spam-Level: X-Spam-Status: No, score=-110.157 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leFF7QH4etfM for ; Fri, 25 Feb 2011 11:45:36 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 468783A67FB for ; Fri, 25 Feb 2011 11:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2221; q=dns/txt; s=iport; t=1298663189; x=1299872789; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=vo1NywnxSNNCnqWuOYVzTK/cHJXrS/ekl3d0cKWHiVs=; b=mRyLzO3FTWWxzyrihK/x/ht2Q6L3YB8g363aPLEn+hsFaLbiGP9lvgRz JMQB1nMI8Qn8+TtBr2WsNqRGDEsQhJmUvw8YSTVzWFZNtME5rIv5cUzOI FMYm1It+qXktD44tVqLxW5gpKZoeBGMUfWCeaC7ZpaVLZbv2SpgNSRMtu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA6WZ02rR7Ht/2dsb2JhbACmO3ShJ5tQhWAEhRCHDYM+ X-IronPort-AV: E=Sophos;i="4.62,227,1297036800"; d="scan'208";a="410911931" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 25 Feb 2011 19:46:29 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1PJkOvu011313; Fri, 25 Feb 2011 19:46:29 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Fri, 25 Feb 2011 11:46:29 -0800 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Fri, 25 Feb 2011 11:46:29 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Fri, 25 Feb 2011 11:46:14 -0800 Message-Id: <758F8FCE-73EA-4CB7-9B61-0BBF4434784C@cisco.com> References: To: Richard Hartmann X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:45:37 -0000 Speaking for myself, I actually don't see a problem with :: representing = one :0000: block. Where there is a problem is when there are two :: = strings in an address; it is in that event ambiguous. in other words, if you want to represent 2001:db8:3:4:5:0:7:8 as = 2001:db8:3:4:5::7:8, the intended interpretation is unambiguous. If you = want to represent 2001:db8:0:0:5:0:0:8 as 2001:db8::5::8, we need to = talk. So for my money, saying that :: represents "one or more" blocks is = fine; the important thing is to have only one such in the string. On Feb 25, 2011, at 11:31 AM, Richard Hartmann wrote: > On Fri, Feb 25, 2011 at 18:22, Russell Heilling = wrote: >=20 >>> 2001:DB8:9300:0:12:0:0:417A >>> 2001:DB8:93::12:0:0:417A >>=20 >> That would actually be compressing 24-bits, which is not allowed by >> the RFC, which refers to "one or more 16-bit fields" >=20 > No, as this are 32 bit: >=20 > 2001:0DB8:9300:0000:0012:0000:0000:417A > ^^ ^^^^ ^^ >=20 > I chose an example as broken as this on purpose. But apparently I > didn't do a very good job in writing the errata, nor in the notes that > accompany it. >=20 > If anyone has any alternate suggestions...? >=20 >=20 >=20 >> As you point out, I think the problem is with the implicit definition >> of a 16-bit field in 2.2.1 >>=20 >> i.e. change: >>=20 >> The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to >> four hexadecimal digits of the eight 16-bit pieces of the = address. >>=20 >> to >>=20 >> The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to >> four hexadecimal digits of the eight 16-bit pieces of the = address, >> subsequently referred to as "fields" >=20 > In that case, everything else would need to be changed to refer to > field as well. This works from the logical POV, but it's probably > easier for humans to have the rule stated explicitly rather than > changing from a weak to a binding implication. >=20 >=20 > Thanks for your feedback, > Richard > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Fri Feb 25 11:55:37 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6FDC3A6831 for ; Fri, 25 Feb 2011 11:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.492 X-Spam-Level: X-Spam-Status: No, score=-103.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdJJmYUqY2YP for ; Fri, 25 Feb 2011 11:55:37 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id D3CAC3A67FB for ; Fri, 25 Feb 2011 11:55:36 -0800 (PST) Received: by wwb22 with SMTP id 22so640788wwb.13 for ; Fri, 25 Feb 2011 11:56:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XNU3p7pMAldqk59h3cklqUmnhwFT4oJHOY/1FJ2fENU=; b=e4gR7/H0JoBDv54iVNbcHZsp/TeoJC0J4xoiSeWKSub9C1wH6Bj12iTol7sXhVDzSa WIYwGtvbZrqbnzqJJeqRY9y7gXM2yxPjNrD6oP3Lls8QoDMKm90OKUmLuW+D/2Y3uPut DJlJ7O+CgD0JkvDEL0Ze2BGzb+ifrFp0jaENs= 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=wE3mHAhdXqHRJIdjAzZMl1GfWBxab77VOJPyb6a9cpNx++zZrEsfzQvxo0Kyq4qafi hKTjbip7iFeSjLnSsSLNQnghubD8rEjsiiyQXPm30iKgern+IyubUtEC/XpIWNP/kr2e qePUMyBELEsywVdulNy2OBtAwZnStM01Bv4zQ= Received: by 10.216.7.205 with SMTP id 55mr7217096wep.96.1298663789098; Fri, 25 Feb 2011 11:56:29 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id h39sm507014wes.29.2011.02.25.11.56.25 (version=SSLv3 cipher=OTHER); Fri, 25 Feb 2011 11:56:28 -0800 (PST) Message-ID: <4D680962.9000207@gmail.com> Date: Sat, 26 Feb 2011 08:56:18 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Richard Hartmann References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:55:38 -0000 On 2011-02-26 08:31, Richard Hartmann wrote: > On Fri, Feb 25, 2011 at 18:22, Russell Heilling wrote: > >>> 2001:DB8:9300:0:12:0:0:417A >>> 2001:DB8:93::12:0:0:417A >> That would actually be compressing 24-bits, which is not allowed by >> the RFC, which refers to "one or more 16-bit fields" > > No, as this are 32 bit: > > 2001:0DB8:9300:0000:0012:0000:0000:417A > ^^ ^^^^ ^^ > > I chose an example as broken as this on purpose. But apparently I > didn't do a very good job in writing the errata, nor in the notes that > accompany it. > > If anyone has any alternate suggestions...? I don't believe there is an error in the RFC that is worth correcting. It is completely clear what it means by a 16 bit field. Brian From dougb@dougbarton.us Fri Feb 25 12:04:58 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CDAF3A6A2E for ; Fri, 25 Feb 2011 12:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86Q85DQ7S4Z5 for ; Fri, 25 Feb 2011 12:04:57 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 0699B3A6817 for ; Fri, 25 Feb 2011 12:04:56 -0800 (PST) Received: (qmail 21579 invoked by uid 399); 25 Feb 2011 20:05:47 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 25 Feb 2011 20:05:47 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D680B9A.9070205@dougbarton.us> Date: Fri, 25 Feb 2011 12:05:46 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian E Carpenter References: <4D680962.9000207@gmail.com> In-Reply-To: <4D680962.9000207@gmail.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 20:04:58 -0000 On 02/25/2011 11:56, Brian E Carpenter wrote: > On 2011-02-26 08:31, Richard Hartmann wrote: >> On Fri, Feb 25, 2011 at 18:22, Russell Heilling wrote: >> >>>> 2001:DB8:9300:0:12:0:0:417A >>>> 2001:DB8:93::12:0:0:417A >>> That would actually be compressing 24-bits, which is not allowed by >>> the RFC, which refers to "one or more 16-bit fields" >> >> No, as this are 32 bit: >> >> 2001:0DB8:9300:0000:0012:0000:0000:417A >> ^^ ^^^^ ^^ >> >> I chose an example as broken as this on purpose. But apparently I >> didn't do a very good job in writing the errata, nor in the notes that >> accompany it. >> >> If anyone has any alternate suggestions...? > > I don't believe there is an error in the RFC that is worth correcting. > It is completely clear what it means by a 16 bit field. Isn't 5952 clear enough on this issue? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From richih.mailinglist@gmail.com Fri Feb 25 14:06:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2BCA3A6A48 for ; Fri, 25 Feb 2011 14:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.739 X-Spam-Level: X-Spam-Status: No, score=-3.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVoqdZHqKUXr for ; Fri, 25 Feb 2011 14:06:03 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id E05BD3A68BC for ; Fri, 25 Feb 2011 14:06:02 -0800 (PST) Received: by gyc15 with SMTP id 15so988131gyc.31 for ; Fri, 25 Feb 2011 14:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=8I4h7UUFmhjigXlCCpakrqbncKU8k3layYPbrGXqjsk=; b=ZRsm/7JGCNxLLQS9FpvXWo7rUviN7Lr6AxnuV/egFErq1l1MGYF39cgBttjQwsl+HY md1/MKYM4D9kdQUuf8pf3mo/9ZlRC3qcVZGtiGXizdaUsxv0d6u2+CcZIdx+FBI9cyU3 /vSsE8OBQdrrPJQfOi60V0Dr6CBJU7obvJUDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=MoZAOsEQ/6SUPX5Btm7vH147/NyJQPVb3xuGU6muBgOe49BauRInXD7jtGDtwCs7VC 394aWTVRGL+bYshmD9NVL4QMgucf6BaorwAMomIvlVoV6CYf9Mo6yyStdJhwwmUQjWdP WsDjZJD/vOJB13iTtEPh92erZB+b4fsUtbp8c= Received: by 10.236.182.2 with SMTP id n2mr5196525yhm.17.1298671616084; Fri, 25 Feb 2011 14:06:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.110.19 with HTTP; Fri, 25 Feb 2011 14:06:36 -0800 (PST) In-Reply-To: <758F8FCE-73EA-4CB7-9B61-0BBF4434784C@cisco.com> References: <758F8FCE-73EA-4CB7-9B61-0BBF4434784C@cisco.com> From: Richard Hartmann Date: Fri, 25 Feb 2011 23:06:36 +0100 Message-ID: To: Fred Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 22:06:03 -0000 On Fri, Feb 25, 2011 at 20:46, Fred Baker wrote: > Speaking for myself, I actually don't see a problem with :: representing = one :0000: block. Where there is a problem is when there are two :: strings= in an address; it is in that event ambiguous. I would tend to agree, but RFC 5952 does it differently. > in other words, if you want to represent 2001:db8:3:4:5:0:7:8 as 2001:db8= :3:4:5::7:8, the intended interpretation is unambiguous. If you want to rep= resent 2001:db8:0:0:5:0:0:8 as 2001:db8::5::8, we need to talk. So for my m= oney, saying that :: represents "one or more" blocks is fine; the important= thing is to have only one such in the string. True, but this is not what my errata is about. Richard From jinmei@isc.org Fri Feb 25 16:26:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6556C3A6A92 for ; Fri, 25 Feb 2011 16:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2uDPij52cLu for ; Fri, 25 Feb 2011 16:26:18 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 75A7A3A6A96 for ; Fri, 25 Feb 2011 16:26:18 -0800 (PST) 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 F18BDC9421; Sat, 26 Feb 2011 00:27:09 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:64:c62c:3ff:fe1f:6c75]) (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 CD8DE216C33; Sat, 26 Feb 2011 00:27:09 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Fri, 25 Feb 2011 16:27:01 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian E Carpenter In-Reply-To: <4D680962.9000207@gmail.com> References: <4D680962.9000207@gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Fri, 25 Feb 2011 16:53:33 -0800 Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 00:26:19 -0000 At Sat, 26 Feb 2011 08:56:18 +1300, Brian E Carpenter wrote: > I don't believe there is an error in the RFC that is worth correcting. > It is completely clear what it means by a 16 bit field. I agree. I wonder what was the background motivation of the errata. Was there a bug report of an implementation that misunderstood :: due to the "ambiguity", or is this just an attempt of a protocol spec lawyer whose job is to find and remove all possible ambiguities from the protocol description, including those that have never caused and will be very unlikely to cause a trouble in practice? If it's the former, I don't necessarily object to the clarification; if it's the latter, I'd rather keep the description concise (by not mentioning the obvious). --- JINMEI, Tatuya Internet Systems Consortium, Inc. From nward@daork.net Fri Feb 25 17:24:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03BC3A6AB0 for ; Fri, 25 Feb 2011 17:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09IaOq-Z0ipH for ; Fri, 25 Feb 2011 17:24:47 -0800 (PST) Received: from unobtainium.braintrust.co.nz (unobtainium.braintrust.co.nz [123.100.101.131]) by core3.amsl.com (Postfix) with ESMTP id F22943A6AAF for ; Fri, 25 Feb 2011 17:24:46 -0800 (PST) Received: from [192.168.0.11] (unknown [121.98.191.176]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id 62066273E5; Sat, 26 Feb 2011 14:25:39 +1300 (NZDT) References: <4D680962.9000207@gmail.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8F5166b) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (8F5166b) From: Nathan Ward Date: Sat, 26 Feb 2011 14:25:34 +1300 To: =?utf-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= X-Mailman-Approved-At: Sat, 26 Feb 2011 10:36:55 -0800 Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 01:24:48 -0000 What ever happened to that draft attempting to name the 16 bit field from la= te last year? Perhaps instead of 16 bit field we could refer to whatever tha= t doc recommends? Apologies if this message is brief, it is sent from my cellphone. On 26/02/2011, at 13:27, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89= wrote: > At Sat, 26 Feb 2011 08:56:18 +1300, > Brian E Carpenter wrote: >=20 >> I don't believe there is an error in the RFC that is worth correcting. >> It is completely clear what it means by a 16 bit field. >=20 > I agree. >=20 > I wonder what was the background motivation of the errata. Was there > a bug report of an implementation that misunderstood :: due to the > "ambiguity", or is this just an attempt of a protocol spec lawyer > whose job is to find and remove all possible ambiguities from the > protocol description, including those that have never caused and will > be very unlikely to cause a trouble in practice? >=20 > If it's the former, I don't necessarily object to the clarification; > if it's the latter, I'd rather keep the description concise (by not > mentioning the obvious). >=20 > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > !DSPAM:22,4d684f48145875308115884! >=20 >=20 From randy@psg.com Mon Feb 28 00:00:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B453A69D5 for ; Mon, 28 Feb 2011 00:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryyzkDOedIzo for ; Mon, 28 Feb 2011 00:00:27 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 9FEE03A6969 for ; Mon, 28 Feb 2011 00:00:26 -0800 (PST) Received: from localhost ([127.0.0.1] helo=96.130.dhcp.conference.apricot.net.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pty2k-000HS1-QP; Mon, 28 Feb 2011 08:01:23 +0000 Date: Mon, 28 Feb 2011 17:01:21 +0900 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@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, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 08:00:28 -0000 the intro seems to go out of its way to justify a unnecessary complex situation which the rest of the document goes on to solve. i.e. --- Whenever a host or small network (which does not meet minimum IPv6 allocation criteria) is connected to multiple upstream networks IPv6 addressing is assigned by each respective service provider resulting in hosts with more than one active IPv6 address. i have a router currently multi-homed which takes a /48 from one provider and announces it to all ipv6 bgp peers. i have seen something like this before but just can't seem to remember where. more interesting and controversial is the trend in rir policy to allow provider independent allocation of /48s to end sites. --- a remote access user may use a VPN to simultaneously connect to a remote network and retain a default route to the Internet for other purposes. red herring --- In IPv4 a common solution to the multihoming problem is to employ NAPT on a border router and use private address space for individual host addressing. common? more like extremely rare and somewhat kinky. --- It is our goal to avoid the IPv6 equivalent of NAT. To reach this goal, mechanisms are needed for end-user hosts to have multiple address assignments and resolve issues such as which address to use for sourcing traffic to which destination good goal. but how did we leap to end-user hosts needing muliple global ip addresses? and this leads in even more complex needs in the subsequent bullets. when first we weave ... --- In short, while IPv6 facilitates hosts having more than one address in the same address scope, the application of this causes significant issues for a host from routing, source address selection and DNS resolution perspectives. A possible consequence of assigning a host multiple identical-scoped addresses is severely impaired IP connectivity. yep. so don't do it. --- the rest of the document is based on the unneeded and complex multi- address assumptions, and therefore gets more and more complex. nancy was right. just say no. randy From bob.hinden@gmail.com Mon Feb 28 00:11:17 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FCA93A6969 for ; Mon, 28 Feb 2011 00:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSNFwmKBJpsD for ; Mon, 28 Feb 2011 00:11:16 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 042763A6917 for ; Mon, 28 Feb 2011 00:11:15 -0800 (PST) Received: by bwz13 with SMTP id 13so4031805bwz.31 for ; Mon, 28 Feb 2011 00:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=d4eFSo/BnPdfPHpZumR9IVow9os4BFzCjrYAIUrqx8s=; b=YCNURPZ3u4wRJ/HPXJJViXF51JIwz05PcX8vQ1ZquOU7gS6V3H9si0UAnB5FV+yCAL ICzazO7JXqu50al+Pd55cAT12DXrkZhGAIwFopZrQchNexVIPPLjzMNdXC41TBMzCTw5 qRkFy60LVFHiF1mPBedlg/GF3JERnjFKOnZes= 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=HNeVq7PpQDr7E4h45n4JpHahnrj7FETC4jKXlVTDoY5jaoFn8KQHULQN6sbwYn10na RrweM+VeHE3/QgCJDsQ8fbLOdNyjVbIsqaddXP1vAgOWNIknsX+aIfXLB2ucVe1+EWtF ZnYvYTAFTkcxeTnHzc7vLBwj2rYMXfZb0OJlw= Received: by 10.204.117.10 with SMTP id o10mr4494310bkq.10.1298880735191; Mon, 28 Feb 2011 00:12:15 -0800 (PST) Received: from [172.24.249.63] (dyn32-131.checkpoint.com [194.29.32.131]) by mx.google.com with ESMTPS id 12sm2320755bki.19.2011.02.28.00.12.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Feb 2011 00:12:14 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Mon, 28 Feb 2011 00:10:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <34A6A61D-CCB5-48B6-93C3-EA5A3365C879@gmail.com> References: To: Richard Hartmann X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 08:11:17 -0000 Richard, On Feb 25, 2011, at 7:07 AM, Richard Hartmann wrote: > Hi all, >=20 >=20 > I submitted an errata [1] for RFC 4291 and as far as I understand it, > an announcement of this should be sent to the relevant WG so people > are aware of this and can comment. The relevant w.g. would be 6man (not v6ops). RFC4291 was developed in = IPv6 w.g., and 6man is the continuation of that. On Feb 25, 2011, at 7:47 AM, Richard Hartmann wrote: > The current RFCs allow me to compress >=20 > 2001:DB8:9300:0:12:0:0:417A >=20 > to >=20 > 2001:DB8:93::12:0:0:417A >=20 > which, uncompresses to >=20 > 2001:DB8:0093:0:12:0:0:417A That is not correct. RFC4291 is clear about compressing 16-bit groups = of zeros, not arbitrary number of continuous zero bits. =20 In your Errata you change the text from: The use of "::" indicates one or more groups of 16 bits of zeros. to: The use of "::" indicates two or more groups of 16 bits of zeros Since there compressing a single group of 16 bits of zeros is not an = error, this is not an errata. You are proposing a change and IMHO that = is not appropriate for an errata. So to quote Brian Carpenter: "I don't believe there is an error in the RFC that is worth = correcting. It is completely clear what it means by a 16 bit field." Bob p.s. Looking at the filed errata for this RFC, I note that Michael = Rushton first filed an errata on the two or more field change on = 2010-08-16, and that Bassam Al-Khaffaf on 2011-02-01 filed another = errata based on yours to the prefix text. I believe all of these errata = should be rejected. From richih.mailinglist@gmail.com Mon Feb 28 02:48:37 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56F883A68EC for ; Mon, 28 Feb 2011 02:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.716 X-Spam-Level: X-Spam-Status: No, score=-3.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJqDqDhT09Qo for ; Mon, 28 Feb 2011 02:48:36 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 5831C3A69D1 for ; Mon, 28 Feb 2011 02:48:35 -0800 (PST) Received: by yib18 with SMTP id 18so589543yib.31 for ; Mon, 28 Feb 2011 02:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2qisIs6PIYM3hNowlQclaJh+8rqGyr7naZXTBTdHc+s=; b=Pr3Oexh5HtezJI1p/SSdnJ15aLt6bRww6sCRMUr9JQBG2XzNTnyGSEkWtWOL+zf/1L 8T2Xn5F4/7ph5aX9GDEzZmlySMi8sVJ/VqqVqRtdzMnjqTbqKZ0CHfTfOqO0NNCVvHt3 qRBvtaBbmAgtSD2GF+lcCxD+qi7ixQm6JoGjM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=lFzFzQmeOu9Qs9u15s5HFLQW4a73hsI2rtjUH+GwwEvG4hyRa5/ROKko5RXGEIn2rm GoyX7T15TiCJ7kiE4aOtuqpl5jfEvwwXEp51Mj4uN2oVLfEqxu4KaqkiFC6e/o6almxz 9Xo9Rnu2ufFUyID+CRin3Ssoty1jrgjcC8gBA= Received: by 10.236.109.180 with SMTP id s40mr9346071yhg.15.1298890175236; Mon, 28 Feb 2011 02:49:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.110.19 with HTTP; Mon, 28 Feb 2011 02:49:15 -0800 (PST) In-Reply-To: References: <758F8FCE-73EA-4CB7-9B61-0BBF4434784C@cisco.com> From: Richard Hartmann Date: Mon, 28 Feb 2011 11:49:15 +0100 Message-ID: To: Fred Baker Content-Type: text/plain; charset=UTF-8 Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 10:48:37 -0000 (Seems I sent this email to Brian directly and not to the list. Re-sending as is) On Fri, Feb 25, 2011 at 20:56, Brian E Carpenter wrote: > I don't believe there is an error in the RFC that is worth correcting. > It is completely clear what it means by a 16 bit field. Is it clear because it's obvious to you or is it clear because it's defined explicitly? Should RFCs depend on "well, I am pretty sure that's what they meant" or "I know what they meant"? And to reduce email load in this thread, but break thread view: On 02/25/2011 11:56, Brian E Carpenter wrote: > Isn't 5952 clear enough on this issue? Unfortunately not. You are free to start and end the sequence of zeros wherever you please. Again, most people would probably not do this and for obvious reasons, but the RFC is not explicit in this regard and that's A Bad Thing, imo. Richard PS: Does this list prefer one reply per thread leaf I am replying to or does it prefer condensed emails at the cost of breaking thread view? From richih.mailinglist@gmail.com Mon Feb 28 02:54:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059473A69F7 for ; Mon, 28 Feb 2011 02:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN3ULBK2NC70 for ; Mon, 28 Feb 2011 02:54:15 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 353DC3A68EC for ; Mon, 28 Feb 2011 02:54:15 -0800 (PST) Received: by ywi6 with SMTP id 6so1383186ywi.31 for ; Mon, 28 Feb 2011 02:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Zx5cQR93t7Go8BoI7DdxZtIvC5YDDmw176/946S0u/k=; b=fLhj9iw0aj+a4LRs7DJ6ELFb5OgWpsMS/UjFyRcpvAq6HI+cXTnDTgL8XFrY/tHwjg C0IAoDxK+fJ/M4RsNKKtamZf2nXVoQuyuGiTOVMqXO+5Qyg/RQUr8qBMujVZR1wA+4zB pv4TP2rTp7Twf7DxuY9yQE9eoQSFUl3K7KY2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=QRGzV0keaTRlazP3JaBhnh1a3TjNttFmHzneLfkHw8zhPB48nUpr5jagcNBHLxiAEo RUY9VCcxePsYKotQycDoYEdp7xux6lg9aRi5YRURc5a9GUG42vOEsECcwCOCkYJ+q0aW qnVGI0l/UqOlEQtkrlbY2t0Y0uJrNB5KwHaFY= Received: by 10.236.26.37 with SMTP id b25mr1560260yha.67.1298890515070; Mon, 28 Feb 2011 02:55:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.110.19 with HTTP; Mon, 28 Feb 2011 02:54:55 -0800 (PST) In-Reply-To: References: <4D680962.9000207@gmail.com> From: Richard Hartmann Date: Mon, 28 Feb 2011 11:54:55 +0100 Message-ID: To: Nathan Ward Content-Type: text/plain; charset=UTF-8 Cc: IPv6 Operations , =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 10:54:16 -0000 2011/2/26 Nathan Ward : > What ever happened to that draft attempting to name the 16 bit field from late last year? Perhaps instead of 16 bit field we could refer to whatever that doc recommends? It does not recommend anything yet, but the next version will suggest hextet as that is what came out far ahead. Richard From richih.mailinglist@gmail.com Mon Feb 28 03:02:51 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495DB3A6B23 for ; Mon, 28 Feb 2011 03:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNCK18wuYfWX for ; Mon, 28 Feb 2011 03:02:50 -0800 (PST) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by core3.amsl.com (Postfix) with ESMTP id 43AF53A68EC for ; Mon, 28 Feb 2011 03:02:50 -0800 (PST) Received: by gwj22 with SMTP id 22so1981690gwj.27 for ; Mon, 28 Feb 2011 03:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=42ywPziP74YZUwOgYuso+q/802QBVJWqV+1g+X4eVBs=; b=oUh+HMVi5Cu3Qt+2DEZ9CyHzNlt1rlSG/R6LMquqBoRaGF2Mu2RMOBePAyDa7PaQED 19XP7661ahDQrnmLZaQYIs7Tbv2unU8Ybu125iBMSUMnP3S2S3/oMRcdjSonslCJY5iW UV0VBiQwhQsAv78SkLw/zWBjIagNwZFNcH9e0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=hECPksNBd9rlWBv2E96ThYxDYVM0MysAc3Af4dLOFv91cXOP36BuPk3sNt7XI4Ql8W s//CHYnhBhqcbxCGFxD/yiDmC/UyenNMvQaZ2HJDsMxooWT+Qagb25aFrsvFb4v1k0f4 2RwcoowBMO/NyJbIKo4MzDCGpG1X2tWElXdv4= Received: by 10.236.109.171 with SMTP id s31mr9410444yhg.2.1298891030052; Mon, 28 Feb 2011 03:03:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.110.19 with HTTP; Mon, 28 Feb 2011 03:03:30 -0800 (PST) In-Reply-To: <34A6A61D-CCB5-48B6-93C3-EA5A3365C879@gmail.com> References: <34A6A61D-CCB5-48B6-93C3-EA5A3365C879@gmail.com> From: Richard Hartmann Date: Mon, 28 Feb 2011 12:03:30 +0100 Message-ID: To: Bob Hinden Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 11:02:51 -0000 On Mon, Feb 28, 2011 at 09:10, Bob Hinden wrote: > The relevant w.g. would be 6man (not v6ops). =C2=A0RFC4291 was developed = in IPv6 w.g., and 6man is the continuation of that. Noted, thanks a lot. > That is not correct. =C2=A0RFC4291 is clear about compressing 16-bit grou= ps of zeros, not arbitrary number of continuous zero bits. It does not define groups. In my example, I compressed a 32-bit group of ze= ros. > Since there compressing a single group of 16 bits of zeros is not an erro= r, this is not an errata. =C2=A0You are proposing a change and IMHO that is= not appropriate for an errata. I don't agree with this change either, but please see RFC 5952, Section 4.2.2 [1]: The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct. Richard [1] http://tools.ietf.org/html/rfc5952#section-4.2.2 From kawamucho@mesh.ad.jp Mon Feb 28 03:39:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491EC3A69E9 for ; Mon, 28 Feb 2011 03:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btjeuif4aKF3 for ; Mon, 28 Feb 2011 03:39:40 -0800 (PST) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by core3.amsl.com (Postfix) with ESMTP id 5B4E33A68F2 for ; Mon, 28 Feb 2011 03:39:39 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id p1SBedTg024242 for ; Mon, 28 Feb 2011 20:40:39 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id p1SBedq24383 for v6ops@ietf.org; Mon, 28 Feb 2011 20:40:39 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id p1SBecum020465 for ; Mon, 28 Feb 2011 20:40:38 +0900 (JST) Received: from mail.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id p1SBecmK003910 for ; Mon, 28 Feb 2011 20:40:38 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id p1SBecT3021188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Feb 2011 20:40:38 +0900 Received: from [127.0.0.1] (edonet164.sys.biglobe.nec.co.jp [10.19.137.164]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id p1SBecgL007670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Feb 2011 20:40:38 +0900 Message-ID: <4D6B89B5.7040207@mesh.ad.jp> Date: Mon, 28 Feb 2011 20:40:37 +0900 From: Seiichi Kawamura User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: v6ops@ietf.org References: <758F8FCE-73EA-4CB7-9B61-0BBF4434784C@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 11:39:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't think this is any 'technical' problem with the current RFC regarding this issue. 2.2.1 and 2.2.2 states the intention and the specs clear enough. I've operated IPv6 networks and services for 7 years now and I've never seen this mistake being made anyways. Why don't you just include the clarification in the address part naming draft if you are so unhappy about this? Seiichi (2011/02/28 19:49), Richard Hartmann wrote: > (Seems I sent this email to Brian directly and not to the list. > Re-sending as is) > > On Fri, Feb 25, 2011 at 20:56, Brian E Carpenter > wrote: > >> I don't believe there is an error in the RFC that is worth correcting. >> It is completely clear what it means by a 16 bit field. > > Is it clear because it's obvious to you or is it clear because it's > defined explicitly? Should RFCs depend on "well, I am pretty sure > that's what they meant" or "I know what they meant"? > > > And to reduce email load in this thread, but break thread view: > > On 02/25/2011 11:56, Brian E Carpenter wrote: > >> Isn't 5952 clear enough on this issue? > > Unfortunately not. You are free to start and end the sequence of zeros > wherever you please. > > > Again, most people would probably not do this and for obvious reasons, > but the RFC is not explicit in this regard and that's A Bad Thing, > imo. > > > > Richard > > > PS: Does this list prefer one reply per thread leaf I am replying to > or does it prefer condensed emails at the cost of breaking thread > view? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iEYEARECAAYFAk1ribUACgkQcrhTYfxyMkIh7QCgh52vsqNbJ6+WKz9gdzpfPm3d wV4AnAmguLxKwguL7i6yWzNAcI+FLLNr =qvMj -----END PGP SIGNATURE----- From bob.hinden@gmail.com Mon Feb 28 03:41:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532373A6B1B for ; Mon, 28 Feb 2011 03:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.529 X-Spam-Level: X-Spam-Status: No, score=-103.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao11O4VV6hyA for ; Mon, 28 Feb 2011 03:41:06 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 557763A68F2 for ; Mon, 28 Feb 2011 03:41:05 -0800 (PST) Received: by bwz13 with SMTP id 13so4159609bwz.31 for ; Mon, 28 Feb 2011 03:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Jca4J+9lKJ4X9+4Wqyc9IhfCujScG5MNpveBQHzR/P4=; b=jf4W2ST8gHn3mu1mYpxBjx28B5Lb1aKwMvGIA8U/Y/tmHlIbOsuhSl+vDgKIU0ve/y scjcq5PVqRxAkLC+CDLoJmdf/3LfJgnZJUGdbbWHvzQmQB64cxcfa94lTPPbuVkdSO1A PfOOp1Rw4E7y/NhB35boID8OcGkb5hxZ3z2Tk= 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=IbZwADscDlAs5yYtrW//C+iu2mjRAesw654XfhYMkXa/fdvS1kKCzRtVYJINiuES/R s63ISuHpDCMeIvpSvyvNcMcVeBTY3IduCiNxkEW8AoDlDVYnPw2TMue3XKOeIOKmNQJ3 8TpuhQ6FFS0HgOdlBDWa0s1HpoQMGjBO2U4dY= Received: by 10.204.35.71 with SMTP id o7mr625972bkd.213.1298893324708; Mon, 28 Feb 2011 03:42:04 -0800 (PST) Received: from [172.24.249.63] (dyn32-131.checkpoint.com [194.29.32.131]) by mx.google.com with ESMTPS id b6sm2455814bkb.22.2011.02.28.03.42.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Feb 2011 03:42:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Mon, 28 Feb 2011 13:41:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <34A6A61D-CCB5-48B6-93C3-EA5A3365C879@gmail.com> To: Richard Hartmann X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 11:41:08 -0000 Richard, On Feb 28, 2011, at 1:03 PM, Richard Hartmann wrote: > On Mon, Feb 28, 2011 at 09:10, Bob Hinden = wrote: >=20 >=20 >> The relevant w.g. would be 6man (not v6ops). RFC4291 was developed = in IPv6 w.g., and 6man is the continuation of that. >=20 > Noted, thanks a lot. >=20 >=20 >> That is not correct. RFC4291 is clear about compressing 16-bit = groups of zeros, not arbitrary number of continuous zero bits. >=20 > It does not define groups. In my example, I compressed a 32-bit group = of zeros. >=20 >=20 >=20 >> Since there compressing a single group of 16 bits of zeros is not an = error, this is not an errata. You are proposing a change and IMHO that = is not appropriate for an errata. >=20 > I don't agree with this change either, but please see RFC 5952, > Section 4.2.2 [1]: >=20 > The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. > For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but > 2001:db8::1:1:1:1:1 is not correct. RFC5952 says: A recommendation for a canonical text representation format of IPv6 addresses is presented in this section. The recommendation in this document is one that complies fully with [RFC4291]. RFC4291 is still correct. If RFC5952 did change RFC4291, which it does = not, this is the correct way to change something in an RFC. It is = incorrect to use the errata process to do this. Bob From teemu.savolainen@nokia.com Mon Feb 28 04:08:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AAF13A684F for ; Mon, 28 Feb 2011 04:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.839 X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74ddHAHXKscW for ; Mon, 28 Feb 2011 04:08:25 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 7D47B3A69C1 for ; Mon, 28 Feb 2011 04:08:25 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1SC8WeM003105; Mon, 28 Feb 2011 14:08:32 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Feb 2011 14:08:14 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 28 Feb 2011 13:08:14 +0100 Received: from 008-AM1MPN1-015.mgdnok.nokia.com ([169.254.5.61]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Mon, 28 Feb 2011 13:08:14 +0100 From: To: , Thread-Topic: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC Thread-Index: AQHL1x3FtS6rDrKywUmdLQdNcrszg5QWzn0w Date: Mon, 28 Feb 2011 12:08:13 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3193C14BB@008-AM1MPN1-015.mgdnok.nokia.com> References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.28.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2011 12:08:14.0939 (UTC) FILETIME=[2D60D2B0:01CBD740] X-Nokia-AV: Clean Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 12:08:26 -0000 > In short, while IPv6 facilitates hosts having more than one address > in the same address scope, the application of this causes significant > issues for a host from routing, source address selection and DNS > resolution perspectives. A possible consequence of assigning a host > multiple identical-scoped addresses is severely impaired IP > connectivity. >=20 > yep. so don't do it. Handsets are increasingly able to technically have multiple radios active a= t the same time (e.g. WLAN and cellular), in addition to having possibiliti= es for IP tunnels.. In the IETF we should clear out obstacles on the path to advanced multi-hom= ing related to Internet Protocol suite itself. Introduction of IPv6 goes a = long way already (no overlapping RFC1918 addresses on multiple interfaces..= ), but we need more to help hosts do wise interface/address selections (rou= ting). A very simple use case of handset multi-homing is browsing over WLAN access= and speaking with VoIP on LTE. Handset must be able to use WLAN access for= default Internet traffic and cellular access for VoIP (and if WLAN disappe= ars, switch all traffic to cellular). Best regards, Teemu From randy@psg.com Mon Feb 28 04:35:34 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7EAC3A6AE4 for ; Mon, 28 Feb 2011 04:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jWa9SD-sML6 for ; Mon, 28 Feb 2011 04:35:34 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id BE2AF3A6AF8 for ; Mon, 28 Feb 2011 04:35:33 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pu2Kw-000IR5-DT; Mon, 28 Feb 2011 12:36:26 +0000 Date: Mon, 28 Feb 2011 21:36:24 +0900 Message-ID: From: Randy Bush To: In-Reply-To: <056B511A55F8AA42A3E492B7DD19A3193C14BB@008-AM1MPN1-015.mgdnok.nokia.com> References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> <056B511A55F8AA42A3E492B7DD19A3193C14BB@008-AM1MPN1-015.mgdnok.nokia.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, v6ops-chairs@tools.ietf.org, ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 12:35:34 -0000 uh oh! i think i get it. this is trying to give a new meaning to the word 'multi-homing' which has been in wide use for a few decades. it means bgp routing with multiple peers (a punny word meaning both any arbitrary bgp neighbor and alternatively one where you only exchange your customers' routes). can we please use a new, or at least different, word here? randy From jav@sics.se Mon Feb 28 04:56:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35B53A6831 for ; Mon, 28 Feb 2011 04:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiUlPvYYk9FP for ; Mon, 28 Feb 2011 04:56:39 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id ABA683A6BDE for ; Mon, 28 Feb 2011 04:56:38 -0800 (PST) Received: from [193.10.66.199] (dab.sics.se [193.10.66.199]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 1B14B4010E; Mon, 28 Feb 2011 13:57:38 +0100 (CET) From: Javier Ubillos To: Simon Perreault In-Reply-To: <4D67BF4C.6020301@viagenie.ca> References: <1298643392.2045.137.camel@dab> <4D67BF4C.6020301@viagenie.ca> Content-Type: text/plain; charset="UTF-8" Date: Mon, 28 Feb 2011 13:57:37 +0100 Message-ID: <1298897857.2099.264.camel@dab> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, 'Rashmi' Subject: Re: [v6ops] Happy-eyeballs - P-value & behavior X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 12:56:40 -0000 On Fri, 2011-02-25 at 09:40 -0500, Simon Perreault wrote: > On 2011-02-25 09:16, Javier Ubillos wrote: *cut* > > If we, instead of dividing by two, divide by -2. We both switch > > protocol, yet move towards zero, expressing that we are not as confident > > about the preference. > > I understand what you're trying to accomplish, but I'm wondering why > you're giving so much more importance to the latest result than to the > accumulated evidence. Why is it important that we switch right away? > Over time, if IPvX maintains its advantage over IPvY, the switch will > happen anyway. I'm unsure about which approach would give the best user-value. I'd be happier with a compromise, where we _do_ react quickly, but still make use of the historic data. Thinking about it a bit: I'm seeing two extreme scenarios, given IPvX and IPvY connectivity: a) We're using IPvX, one connection attempt fails (e.g. dropped syn). * Inverting (and dividing) P -> If there is a large difference between IPvX/Y we run the risk having one connect() to give us a connection of worse service (IPvY). Or, if IPvY is so bad that IPvX still wins, we'll get IPvX + connection delay. * Decrementing P until it 'flips' -> If IPvX is better, we'll still get IPvX. b) We're using IPvX, and IPvX connectivity dies * Inverting (and dividing) P -> We switch over to IPvY w/o delay. * Decrementing P until it 'flips' -> We'll get IPvY connection after connection-delay + max(P)*10ms (4seconds) Conclusion. In the "just missed out a packet" scenario, inverting P is just nuts, i retract my invert-P suggestion ;) In the "IPvX just died" scenario, I guess inverting P is 'better'. But I imagine that scenario to be rarer, and that delays are more acceptable in it. Combined with some test for whether or not we have changed networks, it ought to be negligible. In other words, let's ignore my invert-P suggestion ;) What I wanted to do was to minimize delays for the user. > > * Why should we keep a P-value at all? *cut* > > Perhaps some other congestion-control for SYNs is more appropriate? *cut* > I agree: SYN spamming does not sound like a big issue to me (need data > to back that up). But your algorithm still tries to avoid SYN spamming. Yes, the idea is to use some congestion-control on SYNs. > I'd go further: > > - Always send SYN for both IPv4 & IPv6. > - If the IPv6 connects first, use it and cancel IPv4. > - If the IPv4 connects first, wait 100ms to give IPv6 a chance. > - If IPv6 connects within 100ms, use it and cancel IPv4. > - Otherwise, cancel IPv6 and use IPv4. > > The cool thing about this is that it is super simple and stateless. > There is one tweakable parameter (sounds like a sysctl to me!). > > But it assumes that SYN spamming is not an issue. Any idea on how we can > test that assumption? So, I've run tcpdump at home during the weekend. TCP packets [tcpdump tcp and port 80]: 865890 TCP-syn packets (www, syn-flag only): 20833 That is, of _all_ tcp-packets, ~2.4% where SYN-packets. W/o a P value, that would climb to ~4.81% As a user, I don't care, but perhaps my ISP disagrees :) > > * P-scope > > Currently we're choosing the easy-way out, and keeping a system-wide P. > > However, I'm assuming that a per-destination P is more relevant. Perhaps > > even destination+service. I think destination+service is overkill. We > > _want_ to re-use P and not have to re-init/test too many times. > > We'll continue with a system wide P for now, but we'll likely go the > > per-destination P, hopefully with some nice aggregation feature too. > > I have evidence that a global P is broken. I'll post it soon. My intuitive guess is that a global P does 80% of the work. An IPv6 bottleneck is most likely to be located at the host (assuming a user connects mostly to data-center located and well connected servers). // Javier From jav@sics.se Mon Feb 28 05:52:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853563A6BFC for ; Mon, 28 Feb 2011 05:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, MANGLED_YOUR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fA2omNWE7E2K for ; Mon, 28 Feb 2011 05:52:05 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 4E94D3A6BF9 for ; Mon, 28 Feb 2011 05:52:05 -0800 (PST) Received: from [193.10.66.199] (dab.sics.se [193.10.66.199]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 484014010E; Mon, 28 Feb 2011 14:53:05 +0100 (CET) From: Javier Ubillos To: Andrew Yourtchenko In-Reply-To: References: <1298643392.2045.137.camel@dab> Content-Type: text/plain; charset="UTF-8" Date: Mon, 28 Feb 2011 14:53:04 +0100 Message-ID: <1298901184.2099.320.camel@dab> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, 'Rashmi' Subject: Re: [v6ops] Happy-eyeballs - P-value & behavior X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 13:52:06 -0000 On Fri, 2011-02-25 at 18:35 +0100, Andrew Yourtchenko wrote: *cut* > > > Also, if both connections fail, I suggest we reset P to 0. > > Seems like it won't be a big deal - but do you have more details on the > motivation behind ? If both connections failed, that would say either about the > very sketchy connectivity of the target, or possibly that the source has lost > their connectivity on that interface. > > If the latter, then I think resetting would make sense under the assumption that > we have a different attachment later. If that happens more often than either the > target total unreachability or the 'spurious connectivity losses' (like, bad > connectivity on wireless). Perhaps that's a more sensible approach. If the hosts IPs change, reset P (we *might* have changed networks). > > > > > Multiplying with -1, consider the scenario: > > P is high, favouring IPv6 and delaying IPv4 connections. > > If IPv4 still wins, it means that suddenly is significantly better than > > IPv6 (it won dispite IPv6's headstart). > > Shouldn't we multiply P by -1? > > Does it matter if we start "flapping" between IPv4/6? > > If it does matter, e.g. we want SSL, wouldn't a slow-flapping > > ("normal"-P management) be just as bad? > > I think this would optimize the case where we switched a link - but deoptimize > the case where we had a one-time blip in the connectivity ? After some closer consideration.. Yes, you'r right. I commented on that in the mail to/from Simon Perreault. So, as mentioned above, perhaps a better method to achieve what I'm trying to get at is to detect local address changes. > > > > > > * Why should we keep a P-value at all? > > > > After a mail-exchange with Dan Wing, my conclusion is basically, to > > avoid unnecessary SYN-spamming. Which makes sense to me, SYNs don't have > > a back-off mechanism as an "ordinary" TCP flow has. However, using a > > I think not only SYN-spamming - but also accept()-spamming on the server side I think. > > Arguably from the capacity planning a host should be able to support 2x > accept()-load - but if this is normal scenario, that seems like a bit of a > waste. > > (This is a theoretical view 'in case everyone implemented this', obviously do > not apply in the beginning) > Correct me if I'm mistaken, but... If the responder dosen't allocate the TCB until it recieves the ACK (third handshake packet), then the implementation shouldn't consume much resources until that point (protecting against SYN-floods). And, the initiator, shouldn't be sending two ACKs, but rather one ACK and one RST (as it has chosen a winning socket). > > P-value, where P is a delay to be introduced before trying the "other" > > AF seems sub-optimal to me. > > Perhaps some other congestion-control for SYNs is more appropriate? > > A trivial algorithm _could_ be: > > > > | Always send a SYN for both IPv4 & IPv6 (be aggressive) > > | If some SYN does _not_ receive a SYN-ACK begin > > SYN-congestion-control > > --> Select the best AF (v4 or v6) according to some criteria > > | During time T, only use the best AF > > |* When time T expires, test sending a SYN on the other AF, and see > > if it gets through (multiple tests?) > > | If the congestion is gone go to start (i.e resume an aggressive > > approach) > > | Else - reset T and resume the timid approach. > > > > The reason I'm suggesting a "default" aggressive approach, that I don't > > think that SYN packets make out a noticeable large fraction of the total > > amount of traffic. I've started some captures to compare our offices > > ratio of tcp/tcp-syn packets (overall and for www traffic). > > While we're thinking radically different ideas: how about a "zebra retransmit". > > Start with your "favourite" AF, and if you need to retransmit - then send the > SYN for a different AF. This way the amount of SYNs will always be exactly the > same. If more than 50% of the time over a certain period you fallback - change > your favourite protocol. > > This idea would get nuked by the purists, I suspect :-) Isn't the core problem that we don't want to start with AF_INET6 (our favourite protocol) and have to wait for it to time-out before we switch over to AF_INET? Isn't it that which is what's causing service-providers to start use whitelisting for their AAAA records? > > > > > > * P-scope > > Currently we're choosing the easy-way out, and keeping a system-wide P. > > However, I'm assuming that a per-destination P is more relevant. Perhaps > > even destination+service. I think destination+service is overkill. We > > _want_ to re-use P and not have to re-init/test too many times. > > We'll continue with a system wide P for now, but we'll likely go the > > per-destination P, hopefully with some nice aggregation feature too. > > How is the PMTUD info stored ? I think that the connectivity > characteristics may be related to the PMTUD. P might then sit nicely > in one of the address families alongside with MSS ? I'm not sure I understand what you're getting at. The name-based socket will keep a readable P value. We could allow an interface which could access AF_INET6 data (such as PMTUD). In the happy-eyeballs case, we could also make an interface to get the MSS and have it point to the active socket (IPv4/v6). // Javier From bob.hinden@gmail.com Mon Feb 28 06:13:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D08A83A6C05 for ; Mon, 28 Feb 2011 06:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.54 X-Spam-Level: X-Spam-Status: No, score=-103.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G06SFuwlVL7 for ; Mon, 28 Feb 2011 06:13:53 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B1C3B3A6C06 for ; Mon, 28 Feb 2011 06:13:52 -0800 (PST) Received: by bwz13 with SMTP id 13so4282465bwz.31 for ; Mon, 28 Feb 2011 06:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=qGVbU726F0BN8/4Y2DTO2W9gT8ETO5bMyELHEhsqmGs=; b=b31vnymkUvkyKnlBHkiDHVsyFoKjvpzwYPfpxbq5v4YkFDdPbMZc73uP+28PsbIk2F QKCgjF5R4dkB+kLYnJge0XBKfQzV8UKHBRWaE/1iJk01eDFwjJzvuY1Juc6sDuohXANS Bfjxdvtmtbs7VPVagSA1UkZrx/lbQgXIRN/tk= 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=DMJoU43AjhT1+uuYlGFsOQvM2zY0YzwyyxNPU268WngHO9/HFUF+DCb5L1/3fLMJsD ldaRw8ueqTy5Z/MkUylMj5hu8GO76vD2TRLnltr+iS2ZSpsqCKhlkOPhIXwOBSzH8LfE DWSsuOaQN0sQsgjd0EljkGT9sLpzB/+8ZnIkk= Received: by 10.204.14.204 with SMTP id h12mr4884958bka.183.1298902486161; Mon, 28 Feb 2011 06:14:46 -0800 (PST) Received: from [172.24.249.63] (dyn32-131.checkpoint.com [194.29.32.131]) by mx.google.com with ESMTPS id f20sm2557464bkf.4.2011.02.28.06.14.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Feb 2011 06:14:44 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Mon, 28 Feb 2011 16:14:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <38620E2A-545F-45D0-8503-C74AC3C2480E@gmail.com> References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> <056B511A55F8AA42A3E492B7DD19A3193C14BB@008-AM1MPN1-015.mgdnok.nokia.com> To: Randy Bush X-Mailer: Apple Mail (2.1082) Cc: ron@bonica.org, v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 14:13:53 -0000 Randy, On Feb 28, 2011, at 2:36 PM, Randy Bush wrote: > uh oh! i think i get it. this is trying to give a new meaning to the > word 'multi-homing' which has been in wide use for a few decades. it > means bgp routing with multiple peers (a punny word meaning both any > arbitrary bgp neighbor and alternatively one where you only exchange > your customers' routes). I would argue that multi-homing has meant different things to different = people for a long time as well. >=20 > can we please use a new, or at least different, word here? I agree this would be very useful and is long overdue. The multi-homing = scenario you described is very different from the multi-homing scenario = Teemu described, and these are different from a single site with two = prefixes from two ISP not running BGP, etc., etc. Bob From fred@cisco.com Mon Feb 28 08:55:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563563A6C2D for ; Mon, 28 Feb 2011 08:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4ewFAspLkge for ; Mon, 28 Feb 2011 08:55:11 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 658DD3A6B2F for ; Mon, 28 Feb 2011 08:55:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=418; q=dns/txt; s=iport; t=1298912172; x=1300121772; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=jwxOv6Q3a4BsXxpchVgqeQLUZYHGzZiFW39q5EwqnPQ=; b=QDnh9HLkfrS14f8cDjnRCC7Igq/QSny6TI9gOcK4ImSdCaEflHaesdvK KcFgyn8Yby0IyeUaDy38EO0AZUJnN5NhJJ+7c1dok+PvA+2ebM3wAaEO2 PG/ZNEHae+7rVjIujymOmCE14fUYT4WX2RgV0GvvuFS0F/3v/AdMhg+Gq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPdha02rR7H+/2dsb2JhbACmR3ShGZs2hWEEhRCHDQ X-IronPort-AV: E=Sophos;i="4.62,240,1297036800"; d="scan'208";a="664778198" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 28 Feb 2011 16:56:11 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1SGuB5X011051; Mon, 28 Feb 2011 16:56:11 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: Date: Mon, 28 Feb 2011 08:56:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> To: Randy Bush X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 16:55:12 -0000 On Feb 28, 2011, at 12:01 AM, Randy Bush wrote: > more interesting and controversial is the trend in rir policy to allow > provider independent allocation of /48s to end sites. well, yes. And it is the resulting deaggregation in the route table that = draft-mrw-nat66 is trying to avoid, while retaining the ability for any = end system to send a datagram to any other end system modulo policy = issues.= From ayourtch@cisco.com Mon Feb 28 11:19:37 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BDEB3A6C79 for ; Mon, 28 Feb 2011 11:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDyxxPo3AR6K for ; Mon, 28 Feb 2011 11:19:36 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 4BD403A6820 for ; Mon, 28 Feb 2011 11:19:36 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1SIlIP1026621; Mon, 28 Feb 2011 19:47:18 +0100 (CET) Received: from sweet-brew-7.cisco.com (sweet-brew-7.cisco.com [144.254.10.208]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1SIl4tg009342; Mon, 28 Feb 2011 19:47:04 +0100 (CET) Date: Mon, 28 Feb 2011 19:47:04 +0100 (CET) From: Andrew Yourtchenko To: v6ops@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ayourtch@gmail.com Subject: [v6ops] HEX bar BoF in Prague poll X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 19:19:37 -0000 Folks, we've had a couple of offline discussions that it might be a good idea to have a Bar BoF on happy eyeballs topics, and exchange the practical experiences. So, Happy Eyeballs Xperi(ences|ments) bar bof: http://doodle.com/arq27emxw45z92cd In the spirit of the algorithm, there are two choices - 29th and 31th. By adding some way to contact you back and ticking one or two of the tickboxes onthe URL above you are increasing one or both of the "P" values. The biggest value of P will win on the date. The place will TBD depending on the # of folks. The default is that it will be a bar (since it's a bar bof). The determination of the maximum of P will happen on 16th of March. cheers, andrew From randy@psg.com Mon Feb 28 12:02:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6895E3A6C7E for ; Mon, 28 Feb 2011 12:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4eXOyClfX4N for ; Mon, 28 Feb 2011 12:02:55 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 2E9D43A6C4F for ; Mon, 28 Feb 2011 12:02:55 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pu9Jy-000K3l-T0; Mon, 28 Feb 2011 20:03:55 +0000 Date: Tue, 01 Mar 2011 05:03:53 +0900 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@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: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 20:02:56 -0000 >> more interesting and controversial is the trend in rir policy to >> allow provider independent allocation of /48s to end sites. > well, yes. And it is the resulting deaggregation in the route table > that draft-mrw-nat66 is trying to avoid, while retaining the ability > for any end system to send a datagram to any other end system modulo > policy issues. understood. and, as i have to pay for the routers carrying the paths, i am concerned about the results of the ipv6 marketing efforts of the rir community. many of the folk who were usually route-conservative became ipv6 fanboys and, in a marketing frenzy, forgot their heritage. i think it's the rir policy wonk's version of adding complexity lipstick to the protocol pig. randy From joelja@bogus.com Mon Feb 28 12:04:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858853A6C7F for ; Mon, 28 Feb 2011 12:04:43 -0800 (PST) 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_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7VAQHVmRPPo for ; Mon, 28 Feb 2011 12:04:42 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 40B3F3A67B5 for ; Mon, 28 Feb 2011 12:04:42 -0800 (PST) Received: from 23173jjaeggli.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p1SK5ckh018039 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 28 Feb 2011 20:05:38 GMT (envelope-from joelja@bogus.com) Message-ID: <4D6C000B.1090704@bogus.com> Date: Mon, 28 Feb 2011 12:05:31 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Randy Bush References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> <056B511A55F8AA42A3E492B7DD19A3193C14BB@008-AM1MPN1-015.mgdnok.nokia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Mon, 28 Feb 2011 20:05:41 +0000 (UTC) Cc: ron@bonica.org, v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 20:04:43 -0000 On 2/28/11 4:36 AM, Randy Bush wrote: > uh oh! i think i get it. this is trying to give a new meaning to the > word 'multi-homing' which has been in wide use for a few decades. it > means bgp routing with multiple peers (a punny word meaning both any > arbitrary bgp neighbor and alternatively one where you only exchange > your customers' routes). > > can we please use a new, or at least different, word here? Theoretically the MIF working-group should be working on that definition if I correctly understand their charter. > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From teemu.savolainen@nokia.com Mon Feb 28 12:18:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04CE13A6C76 for ; Mon, 28 Feb 2011 12:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzbECI8-mbM7 for ; Mon, 28 Feb 2011 12:18:47 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 261023A6C71 for ; Mon, 28 Feb 2011 12:18:47 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1SKJd4I029480; Mon, 28 Feb 2011 22:19:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Feb 2011 22:19:09 +0200 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 28 Feb 2011 21:19:09 +0100 Received: from 008-AM1MPN1-015.mgdnok.nokia.com ([169.254.5.61]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0270.002; Mon, 28 Feb 2011 21:19:09 +0100 From: To: , Thread-Topic: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC Thread-Index: AQHL14LZtS6rDrKywUmdLQdNcrszg5QXWC4g Date: Mon, 28 Feb 2011 20:19:08 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3193C19A8@008-AM1MPN1-015.mgdnok.nokia.com> References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> <056B511A55F8AA42A3E492B7DD19A3193C14BB@008-AM1MPN1-015.mgdnok.nokia.com> <4D6C000B.1090704@bogus.com> In-Reply-To: <4D6C000B.1090704@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.93.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2011 20:19:09.0766 (UTC) FILETIME=[C1D2BE60:01CBD784] X-Nokia-AV: Clean Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 20:18:48 -0000 I don't really agree.=20 For what I know multihoming is very commonly used to describe a scenario wh= ere a host has simultaneously multiple uplink ISP connections active.=20 MEXT uses that in this context in RFC6089. HIP uses that in this context in RFC5021. MOBIKE uses that in this context in RFC4555. NETLMM uses that in this context in RFC5213. And I bet there are quite many other RFCs as well. Hence the train to call = it something else went already.=20 I don't know BGP very well, but doesn't this "BGP routing with multiple pee= rs" sound like being "multihomed" as well, but there just happens to be BGP= being used? Best regards, Teemu > -----Original Message----- > From: ext Joel Jaeggli [mailto:joelja@bogus.com] > Sent: 28. helmikuuta 2011 22:06 > To: Randy Bush > Cc: Savolainen Teemu (Nokia-MS/Tampere); v6ops@ietf.org; v6ops- > chairs@tools.ietf.org; ron@bonica.org > Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC >=20 > On 2/28/11 4:36 AM, Randy Bush wrote: > > uh oh! i think i get it. this is trying to give a new meaning to the > > word 'multi-homing' which has been in wide use for a few decades. it > > means bgp routing with multiple peers (a punny word meaning both any > > arbitrary bgp neighbor and alternatively one where you only exchange > > your customers' routes). > > > > can we please use a new, or at least different, word here? >=20 > Theoretically the MIF working-group should be working on that definition > if I correctly understand their charter. >=20 > > randy > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > From randy@psg.com Mon Feb 28 12:19:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8FE3A6C76 for ; Mon, 28 Feb 2011 12:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3ezHIOzWirH for ; Mon, 28 Feb 2011 12:19:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 10B393A6C71 for ; Mon, 28 Feb 2011 12:19:48 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pu9aG-000K7C-6I; Mon, 28 Feb 2011 20:20:44 +0000 Date: Tue, 01 Mar 2011 05:20:42 +0900 Message-ID: From: Randy Bush To: Joel Jaeggli In-Reply-To: <4D6C000B.1090704@bogus.com> References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> <056B511A55F8AA42A3E492B7DD19A3193C14BB@008-AM1MPN1-015.mgdnok.nokia.com> <4D6C000B.1090704@bogus.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: ron@bonica.org, v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 20:19:49 -0000 >> uh oh! i think i get it. this is trying to give a new meaning to the >> word 'multi-homing' which has been in wide use for a few decades. it >> means bgp routing with multiple peers (a punny word meaning both any >> arbitrary bgp neighbor and alternatively one where you only exchange >> your customers' routes). >> >> can we please use a new, or at least different, word here? > > Theoretically the MIF working-group should be working on that definition > if I correctly understand their charter. and, until then, in a droid-like attack, we compound the confusion. layer four switching here we come. multi-attached? randy From teemu.savolainen@nokia.com Mon Feb 28 12:27:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279173A67F8 for ; Mon, 28 Feb 2011 12:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vt0AXzUv9gk8 for ; Mon, 28 Feb 2011 12:27:38 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id CF1C13A67D9 for ; Mon, 28 Feb 2011 12:27:38 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1SKSTC7004058; Mon, 28 Feb 2011 22:28:36 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Feb 2011 22:28:25 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 28 Feb 2011 21:28:24 +0100 Received: from 008-AM1MPN1-015.mgdnok.nokia.com ([169.254.5.61]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Mon, 28 Feb 2011 21:28:23 +0100 From: To: , Thread-Topic: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC Thread-Index: AQHL14T4tS6rDrKywUmdLQdNcrszg5QXXCPQ Date: Mon, 28 Feb 2011 20:28:23 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3193C19E4@008-AM1MPN1-015.mgdnok.nokia.com> References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> <056B511A55F8AA42A3E492B7DD19A3193C14BB@008-AM1MPN1-015.mgdnok.nokia.com> <4D6C000B.1090704@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.93.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2011 20:28:25.0709 (UTC) FILETIME=[0D30E9D0:01CBD786] X-Nokia-AV: Clean Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 20:27:40 -0000 Wikipedia seems to have something to say this: http://en.wikipedia.org/wik= i/Multihoming , covering both our described cases here.. e.g. -- There are several ways to multihome, separate from the actual protocols use= d to do so, amongst which the most important are: Multiple Interfaces, Single IP address per interface: The host has multiple interfaces and each interface has one, or more, IP ad= dresses. If one of the links fails, then its IP address becomes unreachable= , but the other IP addresses will still work. Hosts that have multiple AAAA= or A records enabled can then still be reachable at the penalty of having = the client program time out and retry on the broken address. Existing conne= ctions can't be taken over by the other interface, as TCP does not support = this. To remedy this, one could use SCTP which does allow this situation. H= owever SCTP is not used very much in practice. Multiple Links, Single IP address (Space): This is what in general is meant with Multihoming. With the use of a routin= g protocol, in most cases BGP, the end-site announces this address space to= its upstream links. When one of the links fails, the protocol notices this= on both sides and traffic is not sent over the failing link any more. Usua= lly this method is used to multihome a site and not for single hosts. -- Teemu > -----Original Message----- > From: ext Randy Bush [mailto:randy@psg.com] > Sent: 28. helmikuuta 2011 22:21 > To: Joel Jaeggli > Cc: Savolainen Teemu (Nokia-MS/Tampere); v6ops@ietf.org; v6ops- > chairs@tools.ietf.org; ron@bonica.org > Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC >=20 > >> uh oh! i think i get it. this is trying to give a new meaning to the > >> word 'multi-homing' which has been in wide use for a few decades. it > >> means bgp routing with multiple peers (a punny word meaning both any > >> arbitrary bgp neighbor and alternatively one where you only exchange > >> your customers' routes). > >> > >> can we please use a new, or at least different, word here? > > > > Theoretically the MIF working-group should be working on that definitio= n > > if I correctly understand their charter. >=20 > and, until then, in a droid-like attack, we compound the confusion. > layer four switching here we come. multi-attached? >=20 > randy From brian.e.carpenter@gmail.com Mon Feb 28 12:42:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65A013A6C99 for ; Mon, 28 Feb 2011 12:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.162 X-Spam-Level: X-Spam-Status: No, score=-103.162 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkpodlngNnFY for ; Mon, 28 Feb 2011 12:42:40 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 54D0F3A6C58 for ; Mon, 28 Feb 2011 12:42:40 -0800 (PST) Received: by fxm15 with SMTP id 15so4215206fxm.31 for ; Mon, 28 Feb 2011 12:43:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VKM7mgtfoZUTWqCzU+amtuRA+L4NboawII6Ag4duqrw=; b=EPjnef8Pui2IjRBCqdGPuvGOaGWBlUBK2uBOXzLHtJHolRrNuRbMQkHbwgllj6S5lh szaDNl4P7QVnbM2wrxoMpAkedV2h8oXgMg+BM63NNtScvvUxY686BkH0dnS2bpZko6Fp YzTkgq/4rR+3g23JrNI51Q8scDr0C4xpDwMrc= 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=k7Cy9bQobZvR239fXwwT5oD50UZitP7K9TqQaiAGFG/ZUDx1xp7s6PwoIT+5zIZOkX 4AFKujV4LKxipX9eUjfh3P7VQU8rImbJezYbmMcx+jZZQSyAn4ClGbdValJCLFjeQCZ1 xgSVOv4FZAVuYxSCsoSWRMBL4t6WFIQ+hKZbU= Received: by 10.223.86.13 with SMTP id q13mr7106682fal.53.1298925820993; Mon, 28 Feb 2011 12:43:40 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id n3sm106849faa.5.2011.02.28.12.43.37 (version=SSLv3 cipher=OTHER); Mon, 28 Feb 2011 12:43:40 -0800 (PST) Message-ID: <4D6C08F6.6040400@gmail.com> Date: Tue, 01 Mar 2011 09:43:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Richard Hartmann References: <758F8FCE-73EA-4CB7-9B61-0BBF4434784C@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 20:42:41 -0000 (Although the topic belongs to 6man I am replying here one last time for consistency.) On 2011-02-28 23:49, Richard Hartmann wrote: > (Seems I sent this email to Brian directly and not to the list. > Re-sending as is) > > On Fri, Feb 25, 2011 at 20:56, Brian E Carpenter > wrote: > >> I don't believe there is an error in the RFC that is worth correcting. >> It is completely clear what it means by a 16 bit field. > > Is it clear because it's obvious to you or is it clear because it's > defined explicitly? Should RFCs depend on "well, I am pretty sure > that's what they meant" or "I know what they meant"? " 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to four hexadecimal digits of the eight 16-bit pieces of the address. " That is very clear to me about what it means by a 16-bit piece: there are 8 of them. > > > And to reduce email load in this thread, but break thread view: > > On 02/25/2011 11:56, Brian E Carpenter wrote: > >> Isn't 5952 clear enough on this issue? (Not me in fact, but never mind...) > > Unfortunately not. You are free to start and end the sequence of zeros > wherever you please. The above sentence in 4291 makes it clear that the edge is a 16-bit boundary in each case. BTW, the ABNF discussed in RFC 5954 may interest you. However, you're correct: 5952 and 5954 are only about syntax. It is only 4291 that makes it clear that the : is always on a 16-bit boundary. Brian > > > Again, most people would probably not do this and for obvious reasons, > but the RFC is not explicit in this regard and that's A Bad Thing, > imo. > > > > Richard > > > PS: Does this list prefer one reply per thread leaf I am replying to > or does it prefer condensed emails at the cost of breaking thread > view? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Mon Feb 28 12:54:18 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD0E3A6C7D for ; Mon, 28 Feb 2011 12:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.159 X-Spam-Level: X-Spam-Status: No, score=-103.159 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPlmccHMBVbz for ; Mon, 28 Feb 2011 12:54:16 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C406F3A6C58 for ; Mon, 28 Feb 2011 12:54:15 -0800 (PST) Received: by fxm15 with SMTP id 15so4227599fxm.31 for ; Mon, 28 Feb 2011 12:55:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LFmFoDXCo+pR9Q0x+mGddio8selY2/kMWcEhIgIQq/4=; b=R0d5jPWONj268bSzn6mACFIzyn2ZeqOKJ6feljb2zfQwTVUDU6A/jdu2cqhMOZz2QV wNEth1G0+Fy97HM4FP2qR3EN3ssNMvr8326vd94ZA9JWCDuGcq5uuzOE8TnZPa66A01z 3zjn5L8z/UUp55PwX/F8HHCJAQyfzL2QvVeYc= 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=ti4I+hevfarbGlB8+hlEpeMA1EsX1i6dne90VTuM5KdwjRn/fK+uNGRTXUBvxQH+rg ohOSOonmfQAlS/hW2w7m2ZLk070i8MeHfsZwUUWYOkkKBcCaoW9w1Pb0awyP/GDzRQzB u2xvBi7gad2cI86P6hbBWRDS8X4vyAKIk6rQQ= Received: by 10.223.104.147 with SMTP id p19mr6832533fao.6.1298926515360; Mon, 28 Feb 2011 12:55:15 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id b7sm1796768faa.42.2011.02.28.12.55.10 (version=SSLv3 cipher=OTHER); Mon, 28 Feb 2011 12:55:14 -0800 (PST) Message-ID: <4D6C0BAC.1040505@gmail.com> Date: Tue, 01 Mar 2011 09:55:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> <056B511A55F8AA42A3E492B7DD19A3193C14BB@008-AM1MPN1-015.mgdnok.nokia.com> <4D6C000B.1090704@bogus.com> <056B511A55F8AA42A3E492B7DD19A3193C19A8@008-AM1MPN1-015.mgdnok.nokia.com> In-Reply-To: <056B511A55F8AA42A3E492B7DD19A3193C19A8@008-AM1MPN1-015.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, ron@bonica.org Subject: [v6ops] Er, we had this converstaion before [draft-ietf-v6ops-multihoming-without-nat66 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 20:54:18 -0000 I politely suggest that people re-read RFC 4116 and RFC 3582. And if you really want to avoid repeating several years of discussion, see the other RFCs listed at http://www.ietf.org/wg/concluded/multi6.html and the WG archive at https://ops.ietf.org/lists/multi6/ Multihoming is generic. BGP-4 based multihoming is one solution. Multi-address based multihoming is a fundamental design property of IPv6 (and it does not require multiple interfaces, so MIF is a somewhat different problem). Regards Brian On 2011-03-01 09:19, teemu.savolainen@nokia.com wrote: > I don't really agree. > > For what I know multihoming is very commonly used to describe a scenario where a host has simultaneously multiple uplink ISP connections active. > > MEXT uses that in this context in RFC6089. > > HIP uses that in this context in RFC5021. > > MOBIKE uses that in this context in RFC4555. > > NETLMM uses that in this context in RFC5213. > > And I bet there are quite many other RFCs as well. Hence the train to call it something else went already. > > I don't know BGP very well, but doesn't this "BGP routing with multiple peers" sound like being "multihomed" as well, but there just happens to be BGP being used? > > > Best regards, > > Teemu > >> -----Original Message----- >> From: ext Joel Jaeggli [mailto:joelja@bogus.com] >> Sent: 28. helmikuuta 2011 22:06 >> To: Randy Bush >> Cc: Savolainen Teemu (Nokia-MS/Tampere); v6ops@ietf.org; v6ops- >> chairs@tools.ietf.org; ron@bonica.org >> Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC >> >> On 2/28/11 4:36 AM, Randy Bush wrote: >>> uh oh! i think i get it. this is trying to give a new meaning to the >>> word 'multi-homing' which has been in wide use for a few decades. it >>> means bgp routing with multiple peers (a punny word meaning both any >>> arbitrary bgp neighbor and alternatively one where you only exchange >>> your customers' routes). >>> >>> can we please use a new, or at least different, word here? >> Theoretically the MIF working-group should be working on that definition >> if I correctly understand their charter. >> >>> randy >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Mon Feb 28 13:01:54 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793F33A6A66 for ; Mon, 28 Feb 2011 13:01:54 -0800 (PST) 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.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+dYtniSq59F for ; Mon, 28 Feb 2011 13:01:53 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E968C3A6A14 for ; Mon, 28 Feb 2011 13:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2980; q=dns/txt; s=iport; t=1298926974; x=1300136574; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=sgOzIRVGAC28tcNJ0KCFKHS5a90Spt+wqLcE083QUqU=; b=gMcV5RfLvPg95frWz/zR3rc3rrmSWOTD/+32Qeu2NPQTTMvODZDZp5kt bz200axaSE77nKFEQdZ7JIW2XUs6dKwBigHGS0DJnqHnwWg+EPi8ks02V Us/U+fu5SP1IuG0GeFc5id/fVF5uMRBxdgAtfmOv2J+X3LVzV9IdvYvJ3 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI+ca02rR7Ht/2dsb2JhbACmRXSgF5tdhWEEhQ+HDQ X-IronPort-AV: E=Sophos;i="4.62,242,1297036800"; d="scan'208";a="266660599" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 28 Feb 2011 21:02:52 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1SL2pJN029778; Mon, 28 Feb 2011 21:02:51 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <056B511A55F8AA42A3E492B7DD19A3193C19A8@008-AM1MPN1-015.mgdnok.nokia.com> Date: Mon, 28 Feb 2011 13:02:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <00DFEA69-DD43-49C0-A012-360BDCB41171@cisco.com> References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> <056B511A55F8AA42A3E492B7DD19A3193C14BB@008-AM1MPN1-015.mgdnok.nokia.com> <4D6C000B.1090704@bogus.com> <056B511A55F8AA42A3E492B7DD19A3193C19A8@008-AM1MPN1-015.mgdnok.nokia.com> To: savolainen teemu , Randy Bush X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 21:01:54 -0000 On Feb 28, 2011, at 12:19 PM, wrote: > For what I know multihoming is very commonly used to describe a = scenario where a host has simultaneously multiple uplink ISP connections = active.=20 There are 185 RFCs and I-don't-know-how-many Internet Drafts (that may = or may not ever become RFCs) that discuss multihoming. And five IENs. The oldest use of the term I could find is in IEN 110, dated 1979. It = uses the term without definition (it must have been in the air at the = time), but states that 3. Hosts which are deliberately multihomed on distinct networks should be able to recover from interface failures, but by mechanisms above the TCP/internet layer, not within them. So, clearly the expectation there was that "multihomed" implied = "[multiple] distinct networks" and the ability for a host to recover = from failures. IEN 178 has a section with that title. It's introductory comment is that A subscriber may want to have multiple connections to a communication system for reliability or performance reasons. It goes on to describe having multiple addresses, the ability to use any = of them, and the ability to optimize its use of them, among other = things. The first definition I find that can be described as a "definition" is = in RFC 1122; RFC 1123 continues the discussion. A host is generally said to be multihomed if it has more than one interface to the same or to different networks. See Section 1.1.3 on "Terminology". And by the way has a second 3.3.4 on "local multihoming". Since RFC 1122 = is "host" requirements, it doesn't discuss the multihoming of a network. = What it addresses (no pun intended) is a host that is part of two or = more subnets, whether that means two or more interfaces or one interface = with multiple subnets. RFC 1127, which is Bob Braden's "Perspective on the Host Requirements = RFCs", goes on to discuss "AS Multihoming", which he defines as=20 multihomed AS: an AS that has more than one connection to other ASs, but refuses to carry transit traffic. Bringing this back to the draft in question, my understanding is that = the authors are working from the model in which: a) a residential/SOHO/other-edge-network has multiple upstreams b) said network has at least one CPE c) the multiple upstreams provide a prefix each d) as a result, the residential/SOHO/other-edge-network has multiple = prefixes overlaid in it.=20 Every host, by RFC 1122's definition, is multihomed (it has more than = one subnet, regardless of physical connectivity), and the network is = multihomed (it has more than one upstream. Did I miss something? Randy's description of multihomed networks he = runes is perfectly accurate. But BGP is not a requirement for = multihoming; what is a requirement is "multiple addresses" or "multiple = upstreams".= From brian.e.carpenter@gmail.com Mon Feb 28 13:03:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7263A6CA6 for ; Mon, 28 Feb 2011 13:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.456 X-Spam-Level: X-Spam-Status: No, score=-103.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KErn1MZi3id for ; Mon, 28 Feb 2011 13:03:22 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id DF60C3A6CA5 for ; Mon, 28 Feb 2011 13:03:21 -0800 (PST) Received: by fxm15 with SMTP id 15so4236970fxm.31 for ; Mon, 28 Feb 2011 13:04:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ObRIPOJBuHCQu3YgjjiltW45qF3vwGbGxTafwzq1SFM=; b=aa847qysLAcLw0/TkM/7COC/p3oknt8XI/KCsuNVV3w6XTxIH8f5PcK4JElOGKvite NGT/sHiwgX+R5lT5i2sRDvqfaLimxDt24mH0JkoRnkdidg/LhywSGsI7siQImC1IIhXD LXTTULza/7z+vtAh9S5wApMsB4nxXKOOfKeXI= 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=t38gNW7lOs3osyCUtnc0mPH77SLGqFpPbSNnavx3Yv1nAw0QSKQ4Xs4r+70y+r023Y GPIg6B6Xib5NBfVBvjbS5ibYlOwwbKftNey4EXltcfhie+TCkQ6L34dGV36IEh8UlZjC FZ6+X5OJUh6BwGByFX8GM0XdKVfmvnHL6+W00= Received: by 10.223.103.12 with SMTP id i12mr7249517fao.43.1298927062356; Mon, 28 Feb 2011 13:04:22 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id y1sm1806063fak.15.2011.02.28.13.04.18 (version=SSLv3 cipher=OTHER); Mon, 28 Feb 2011 13:04:21 -0800 (PST) Message-ID: <4D6C0DCF.4090003@gmail.com> Date: Tue, 01 Mar 2011 10:04:15 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] NAPT-based multihoming [draft-ietf-v6ops-multihoming-without-nat66 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 21:03:23 -0000 On 2011-02-28 21:01, Randy Bush wrote: ... > > In IPv4 a common solution to the multihoming problem is to employ > NAPT on a border router and use private address space for individual > host addressing. > > common? more like extremely rare and somewhat kinky. Huh? Having a different NAPT at each egress is a common technique in large entreprise networks, so that each egress is PA-addressed as far as the ISP is concerned. Then internally the enterprise network uses whatever prefix it wants, either IANA-allocated or RFC 1918. Of course, externally visible servers have to be in a DMZ that isn't NATted, but that is a tiny minority of the hosts in such an enterprise. The ISPs don't know this is happening, just as my ISP at home doesn't know that I have a consumer NAT. NPTv6 does exactly this. Brian From randy@psg.com Mon Feb 28 13:04:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F083A6C91 for ; Mon, 28 Feb 2011 13:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY1gMzR6411M for ; Mon, 28 Feb 2011 13:04:43 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id BCB6C3A6A25 for ; Mon, 28 Feb 2011 13:04:42 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PuAHf-000KOU-11; Mon, 28 Feb 2011 21:05:35 +0000 Date: Tue, 01 Mar 2011 06:05:33 +0900 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: <00DFEA69-DD43-49C0-A012-360BDCB41171@cisco.com> References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> <056B511A55F8AA42A3E492B7DD19A3193C14BB@008-AM1MPN1-015.mgdnok.nokia.com> <4D6C000B.1090704@bogus.com> <056B511A55F8AA42A3E492B7DD19A3193C19A8@008-AM1MPN1-015.mgdnok.nokia.com> <00DFEA69-DD43-49C0-A012-360BDCB41171@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: IPv6 Operations , V6ops Chairs , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 21:04:43 -0000 > Randy's description of multihomed networks he runes is perfectly > accurate. But BGP is not a requirement for multihoming; what is a > requirement is "multiple addresses" or "multiple upstreams". i recant randy From fred@cisco.com Mon Feb 28 13:48:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F3C3A68B1 for ; Mon, 28 Feb 2011 13:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.463 X-Spam-Level: X-Spam-Status: No, score=-110.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k87PZxRTgVxe for ; Mon, 28 Feb 2011 13:48:39 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id EBE733A6C72 for ; Mon, 28 Feb 2011 13:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1127; q=dns/txt; s=iport; t=1298929780; x=1300139380; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=GEClUQl72K8+diaJsldqoOWOVOtZJ4vJJSyNfuHsRao=; b=ktf/7pZzaNg8X69LZWZaREcKrkWBxnPqqlpAdmy0fLHfAEyDg2T3T+RV kQveoFgiBCtf/Ux7Ok4MEBQhM2BrFCyEJKhr7WOhnuQNTRN34HXfvHcCW OF1PptiddDE3hIScfQ2jNTHNQOAHmZJ9LjJ8OeJ0qYvAbehDzH7nKd5WL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABuna02rR7H+/2dsb2JhbACmRXSgAptihWEEhQ+HDQ X-IronPort-AV: E=Sophos;i="4.62,242,1297036800"; d="scan'208";a="316002225" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 28 Feb 2011 21:49:40 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1SLn6Fg002367 for ; Mon, 28 Feb 2011 21:49:40 GMT From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2011 13:49:39 -0800 Message-Id: To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [v6ops] Agenda as it is today X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 21:48:40 -0000 Data on the working group's current state: = http://datatracker.ietf.org/wg/v6ops/ Current drafts for IETF 80 include draft-carpenter-v6ops-6to4-teredo-advisory-02.txt draft-hu-v6ops-radius-issues-ipv6-00.txt draft-korhonen-v6ops-3gpp-eps-06.txt draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-01.txt draft-troan-v6ops-6to4-to-historic-00.txt We also have talks from Teemu Savolainen on Happy Eyeballs-related = testing, and Geoff Huston on measured behavior of 6to4 and Teredo.=20 Drafts that have not been updated since IETF 79 and are not somewhere = include draft-denog-v6ops-addresspartnaming draft-ietf-v6ops-tunnel-loops draft-kuarsingh-v6ops-6to4-provider-managed-tunnel draft-sarikaya-v6ops-prefix-delegation draft-sunq-v6ops-ivi-sp draft-tsou-v6ops-mobile-transition-guide draft-vandevelde-v6ops-harmful-tunnels draft-wing-v6ops-happy-eyeballs-ipv6 draft-yang-v6ops-v4v6tran-bb-transition-guide If folks want time on the agenda, this week is the week for -00 drafts, = and next week for updated drafts.= From brian.e.carpenter@gmail.com Mon Feb 28 13:50:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61E373A6CB2 for ; Mon, 28 Feb 2011 13:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.459 X-Spam-Level: X-Spam-Status: No, score=-103.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWF0ZEhws5DQ for ; Mon, 28 Feb 2011 13:50:01 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id A0AC33A6CA2 for ; Mon, 28 Feb 2011 13:50:00 -0800 (PST) Received: by fxm15 with SMTP id 15so4282066fxm.31 for ; Mon, 28 Feb 2011 13:51:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hrxmbqs+ra/dQQDrlkd1GtLs/XaEoH2QLnp7GQbqNz0=; b=SPStb6DPcvpcoAVWkNUxe/WiNZvyNkMDUpkv5M91lZrn7DGdo3Mnc4Atd1hMPRW09W 8YRMMRPwO9OUjTk3H32n1WmFLlkcslkQpWK/essKKrFDhWZuT8qhDPqbZaVVf4cBeVMW xn5s50HJvmPZoz0Ji4d0MWIU6rLhAYYGL3uYE= 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=k8oKsxkqDfXWJTUHVeth2Eg+c+15KKi7NEsDhNQxdTKjv1AeW39EyFE7lU7vgoDYh2 aZ9Il+otNg+i+Rc2Co8MTbftWHAWK3uFEKkLWLZfuKK8bt+9rGTPT5mkMhDYfD0cXrkS aVnSMbKNCYz+lhaxIVli4UA9SNv8N2mwJG2js= Received: by 10.223.100.2 with SMTP id w2mr7073517fan.115.1298929861187; Mon, 28 Feb 2011 13:51:01 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id y1sm1827996fak.39.2011.02.28.13.50.57 (version=SSLv3 cipher=OTHER); Mon, 28 Feb 2011 13:51:00 -0800 (PST) Message-ID: <4D6C18BE.2020606@gmail.com> Date: Tue, 01 Mar 2011 10:50:54 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> In-Reply-To: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 21:50:05 -0000 Hi, I think this draft still needs a lot of work. First, quite a bit of rewriting is needed in the Introduction. > Multihoming is a blanket term to describe a host or small network > that is connected to more than one upstream network. I suggest a reference to RFC 3582 here, where the IPv6 requirements are listed. > For example, a remote access user may use a VPN to > simultaneously connect to a remote network and retain a default route > to the Internet for other purposes. I don't think this is really a red herring. It's a very common scenario but it does amount to MIF rather than multihoming, since the VPN usually appears as a virtual interface. The draft should focus on MH not on MIF, I think. > In IPv4 a common solution to the multihoming problem is to employ > NAPT... Probably this should start by saying that RFC 4116 is the most common method. It should be made clear that avoiding that method, with its built-in scaling problem, is of equal importance to avoiding NAPT. There should also be a discussion of NPTv6, which also avoids NAPT and RFC 4116. Explain why the proposed approach is a better choice than NPT6. There needs to be a clear statement that the underlying model is that having multiple PA prefixes for a site is normal. (And once you say that, you also need to explain why the proposed solution is better than shim6, or how it will interact with shim6). > 2. Terminology ... > NAT66 or IPv6 NAT The terms "NAT66" and "IPv6 NAT" refer to > [I-D.mrw-nat66]. That is plain wrong. Now I don't understand whether you are trying to avoid NAPT66 (which is evil) or NPT6 (which is much less evil, and is the actual topic of draft-mrw-nat66). This needs cleaning up throughout the draft. > 3.2. Multihomed network environment > > In an IPv6 multihomed network, a host is assigned two or more IPv6 > addresses and DNS resolvers from independent service provider > networks. Here I have to agree with Randy - this is not *the* model for IPv6 MH, it is only one model (which you define earlier as MHMP). And why mention separate DNS resolvers? Since DNS is a single namespace, you should get the same (multiple) AAAA records from any resolver. If not, there's a bug in DNS. > ...or use a DNS response from an incorrect > service provider that may result in impaired IP connectivity. No, no, no. Not unless you intend to recommend DNS cheating by CDNs. Making DNS cheating work should never be an IETF goal. > 4.3. DNS server selection I am very worried by this section. I think this draft should focus on routing issues; just assume that you get back all the AAAA records for the target in random order, and go from there. > 5. Requirements > > This section describes requirements that any solution multi-address > and multi-uplink architectures need to meet. I'm puzzled by this section. 1. It seems to cover all kinds of solutions and not just the solution proposed by this document. 2. It should be much earlier in the document, right after the Introduction. 3. It mixes MH and MIF issues. 4. It needs to explain what is added or changed compared to RFC 3582. > 6.3. DNS resolver selection See above. I think this should be out of scope. > 7.1. IPv6 NAT Drop this except for a reference to NPT6. > 7.2. Co-exisitence consideration I think this is no use as it stands because of the last sentence: > The implementation of identifying non-MHMP hosts and NAT policy is > outside the scope of this document. I think all you can say is that hosts that don't support MHMP MAY be supported by NPT6 or shim6, and if they don't have either of those they will not get the benefit of multihoming. That is today's situation anyway, so you have done no harm. > 8. Security Considerations > > This document does not define any new mechanisms. Each solution > mechanisms should consider security risks independently. Security > risks that occur as a result of combining solution mechanisms should > be considered in another document. Er, no. Those risks should be analysed right here in this document. Also, refer to RFC 4218. Which of those threats apply, and are there any new ones? Brian